> Date: Tue, 10 Jun 2014 23:54:41 +0100
> From: Pádraig Brady
> CC: bug-gnulib@gnu.org
>
> Pushed the attached, thanks.
Great, thanks.
> Date: Tue, 10 Jun 2014 23:53:50 +0100
> From: Pádraig Brady
> CC: bug-gnulib@gnu.org
>
> > Right you are. So this should be something like
> >
> > clock_t tnow = clock ();
> > if (tend >= tnow)
> > wait_timeout = tend - tnow;
> > else
> > wait_timeout = 0;
>
> Pushed the attach
On Tue, Jun 10, 2014 at 5:38 PM, Bruce Korb wrote:
> Or maybe:
>
> #ifdef TIME_MAX
> #define TIME_LIMIT TIME_MAX
> #else
> #define TIME_LIMIT (((time_t)~0) >> 1)
> #endif
Why impose such a limit?
I'd go with TYPE_MAXIMUM (time_t).
On 06/01/14 10:04, Jonas 'Sortie' Termansen wrote:
Hi,
I noticed that lib/parse-duration.c does:
#define TIME_MAX 0x7FFF
This is naturally entirely unacceptable as the 2038 bug ((time_t)
INT32_MAX) is coming up soon
OK, I promise to fix it within the next 24 years.
In truth, since this
On 06/10/2014 03:43 AM, Eli Zaretskii wrote:
>> Date: Tue, 10 Jun 2014 00:42:22 +0100
>> From: Pádraig Brady
>> CC: bug-gnulib@gnu.org
>>
>>> . The value is constant: every call to 'times' within the same
>>> process returns the same value. Callers generally expect the
>>> value to chan
On 06/10/2014 03:47 AM, Eli Zaretskii wrote:
>> Date: Tue, 10 Jun 2014 00:55:14 +0100
>> From: Pádraig Brady
>> CC: bug-gnulib@gnu.org
>>
>>> + /* How much is left to wait? */
>>> + if (wait_timeout != INFINITE)
>>> +{
>>> + wait_timeout = tend - clock ();
>>> + if (wait_timeout <
On 06/09/2014 05:11 PM, Pádraig Brady wrote:
> On 06/09/2014 04:16 PM, Michael Goffioul wrote:
>> See the following threads, with problem reporting and solution testing:
>> http://lists.gnu.org/archive/html/bug-gnulib/2012-12/msg00092.html
>> http://lists.gnu.org/archive/html/bug-gnulib/2013-01/msg
Currently, gnulib's nl_langinfo provides on C-locale names for week
days and months, thus any program that uses it can only speak English
in these contexts.
How about the following patch, which uses strftime to produce
localized names for these?
--- lib/nl_langinfo.c~0 2014-02-15 01:00:33 +0200
+
On Tue, Jun 10, 2014 at 8:47 AM, Phillip Susi wrote:
> I tried making a release candidate by appending -rc1 to the normal version
> number, and it seems that this makes git-version-gen puke and come up with
> UNKNOWN as the version. It looks like it has some code for dealing with old
> versions o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I tried making a release candidate by appending -rc1 to the normal version
number, and it seems that this makes git-version-gen puke and come up with
UNKNOWN as the version. It looks like it has some code for dealing with old
versions of git-descr
10 matches
Mail list logo
