Eric Blake wrote:
> According to Jim Meyering on 9/19/2009 10:46 AM:
>> +++ b/tests/test-posixtm.c
>> @@ -0,0 +1,175 @@
>> +/* Test that openat_safer leave standard fds alone.
>
> Really? This line is a bit too much copy-n-paste ;)
Hah! Thanks.
This works better:
>From 3e2faf235348ba68f0fd19bc3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 9/19/2009 10:46 AM:
> +++ b/tests/test-posixtm.c
> @@ -0,0 +1,175 @@
> +/* Test that openat_safer leave standard fds alone.
Really? This line is a bit too much copy-n-paste ;)
- --
Don't work too hard, make some time for
Jim Meyering wrote:
> Paolo Bonzini wrote:
>
>>> { "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>>> { "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>>
>> Uhm, why 2002? You could pre-generate all possible outputs from 2009
>> to 2038 and only o
Eric Blake wrote:
> Jim Meyering meyering.net> writes:
>> FYI, here's the new test, in case anyone feels like reviewing:
>>
>> +static struct posixtm_test T[] =
>> + {
>> +{ "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>> +{ "12131415.16", 13, " 1039788916 Fri D
Paolo Bonzini wrote:
>> { "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>> { "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
>
> Uhm, why 2002? You could pre-generate all possible outputs from 2009
> to 2038 and only one of them will be checked.
{ "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
{ "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
Uhm, why 2002? You could pre-generate all possible outputs from 2009 to
2038 and only one of them will be checked.
Paolo
Jim Meyering meyering.net> writes:
> FYI, here's the new test, in case anyone feels like reviewing:
>
> +static struct posixtm_test T[] =
> + {
> +{ "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
> +{ "12131415.16", 13, " 1039788916 Fri Dec 13 14:15:16 2002" },
I
Jim Meyering wrote:
> Paolo Bonzini wrote:
Going backwards from "cal 1 1" you can see that in
the Julian calendar 01-Jan- was a Thursday, but that's not so
relevant.
However cal can help seeing that 01-Jan- is a Saturday in
Gregorian proleptic calendar (i.e. ex
Paolo Bonzini wrote:
>>> Going backwards from "cal 1 1" you can see that in
>>> the Julian calendar 01-Jan- was a Thursday, but that's not so
>>> relevant.
>>>
>>> However cal can help seeing that 01-Jan- is a Saturday in
>>> Gregorian proleptic calendar (i.e. extending Gregorian calendar b
Going backwards from "cal 1 1" you can see that in
the Julian calendar 01-Jan- was a Thursday, but that's not so
relevant.
However cal can help seeing that 01-Jan- is a Saturday in
Gregorian proleptic calendar (i.e. extending Gregorian calendar before
the day when it was adopted). 400 ye
Paolo Bonzini wrote:
>> --- - 2009-09-14 14:32:58.934253776 +0200
>> +++ in 2009-09-14 14:32:58.930840392 +0200
>> @@ -1,6 +1,6 @@
>> -12131415.16 13 1260713716 Sun Dec 13 14:15:16 2009
>> -12131415.16 13 1260713716 Sun Dec 13 14:15:16 2009
>> -01010
--- - 2009-09-14 14:32:58.934253776 +0200
+++ in 2009-09-14 14:32:58.930840392 +0200
@@ -1,6 +1,6 @@
-12131415.16 13 1260713716 Sun Dec 13 14:15:16 2009
-12131415.16 13 1260713716 Sun Dec 13 14:15:16 2009
-0101.00 13 -62167219200 Sat Jan
c9e60c973e614 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Sun, 13 Sep 2009 00:35:49 +0200
Subject: [PATCH] posixtm: don't reject a time with "60" as the number of seconds
* lib/posixtm.c (posixtime): The code to reject invalid dates would
also reject a time specified with
13 matches
Mail list logo