Patchwork tests: AIX can't handle negative date in test-dirstate.t

login
register
mail settings
Submitter Jim Hague
Date April 30, 2013, 4:34 p.m.
Message ID <8c560ad1cdc40b2a9fd7.1367339663@hagrid.bear-cave.org.uk>
Download mbox | patch
Permalink /patch/1513/
State Accepted
Commit 8c560ad1cdc40b2a9fd7617200daa9b7120f06a6
Headers show

Comments

Jim Hague - April 30, 2013, 4:34 p.m.
# HG changeset patch
# User Jim Hague <jim.hague@acm.org>
# Date 1367330193 -3600
# Branch stable
# Node ID 8c560ad1cdc40b2a9fd7617200daa9b7120f06a6
# Parent  f01a351db79106ba96ac6d527cf69944fd98e665
tests: AIX can't handle negative date in test-dirstate.t

test-dirstate.t fails on AIX in the absurd date test. AIX touch errors on
any date prior to 1970. AIX mktime() gives an error on such dates, so the
problem is deeper than touch and attempts to work around touch in Python
failed.

Give up. Add an AIX test to hghave and skip the absurd date test on AIX.
Mads Kiilerich - April 30, 2013, 5:58 p.m.
On 04/30/2013 06:34 PM, Jim Hague wrote:
> # HG changeset patch
> # User Jim Hague <jim.hague@acm.org>
> # Date 1367330193 -3600
> # Branch stable
> # Node ID 8c560ad1cdc40b2a9fd7617200daa9b7120f06a6
> # Parent  f01a351db79106ba96ac6d527cf69944fd98e665
> tests: AIX can't handle negative date in test-dirstate.t
>
> test-dirstate.t fails on AIX in the absurd date test. AIX touch errors on
> any date prior to 1970. AIX mktime() gives an error on such dates, so the
> problem is deeper than touch and attempts to work around touch in Python
> failed.
>
> Give up. Add an AIX test to hghave and skip the absurd date test on AIX.

For reference, a similar problem was "handled" in 
http://selenic.com/hg/rev/4720d2c903a2 .

This fix is less aggressive than the previous and seems better, so the 
prior art is only mentioned to say that it shouldn't be used as prior 
art ;-)

I don't know how mktime failed for you or what kind of 32 bit systems 
Thomas saw the problem on and how its mktime would handle "y-20", but it 
would perhaps be possible and even better to guard both tests by 
'mktime() can handle odd dates'.

/Mads

> diff -r f01a351db791 -r 8c560ad1cdc4 tests/hghave.py
> --- a/tests/hghave.py	Fri Apr 26 01:12:03 2013 +0900
> +++ b/tests/hghave.py	Tue Apr 30 14:56:33 2013 +0100
> @@ -274,6 +274,9 @@
>   def has_msys():
>       return os.getenv('MSYSTEM')
>   
> +def has_aix():
> +    return sys.platform.startswith("aix")
> +
>   checks = {
>       "true": (lambda: True, "yak shaving"),
>       "false": (lambda: False, "nail clipper"),
> @@ -314,4 +317,5 @@
>       "unix-permissions": (has_unix_permissions, "unix-style permissions"),
>       "windows": (has_windows, "Windows"),
>       "msys": (has_msys, "Windows with MSYS"),
> +    "aix": (has_aix, "AIX"),
>   }
> diff -r f01a351db791 -r 8c560ad1cdc4 tests/test-dirstate.t
> --- a/tests/test-dirstate.t	Fri Apr 26 01:12:03 2013 +0900
> +++ b/tests/test-dirstate.t	Tue Apr 30 14:56:33 2013 +0100
> @@ -55,8 +55,9 @@
>   
>   Test modulo storage/comparison of absurd dates:
>   
> +#if no-aix
>     $ touch -t 195001011200 a
>     $ hg st
>     $ hg debugstate
>     n 644          2 2018-01-19 15:14:08 a
> -
> +#endif
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
Jim Hague - April 30, 2013, 11:21 p.m.
On Tuesday 30 Apr 2013 18:58:42 Mads Kiilerich wrote:
> On 04/30/2013 06:34 PM, Jim Hague wrote:
> > test-dirstate.t fails on AIX in the absurd date test. AIX touch errors on
> > any date prior to 1970. AIX mktime() gives an error on such dates, so the
> > problem is deeper than touch and attempts to work around touch in Python
> > failed.
> > 
> > Give up. Add an AIX test to hghave and skip the absurd date test on AIX.
> 
> For reference, a similar problem was "handled" in
> http://selenic.com/hg/rev/4720d2c903a2 .

I saw that fix.

> This fix is less aggressive than the previous and seems better, so the
> prior art is only mentioned to say that it shouldn't be used as prior
> art ;-)

As you say, the fix did seem a bit brutal to be used as prior art :-)

> I don't know how mktime failed for you or what kind of 32 bit systems
> Thomas saw the problem on and how its mktime would handle "y-20", but it
> would perhaps be possible and even better to guard both tests by
> 'mktime() can handle odd dates'.

I did wonder about doing that. But I think to reintroduce the test Thomas 
deleted would require two different guards.

The deleted absurd date test checked truncation on a date too far in the 
future to be represented as a 32bit signed (or unsigned) quantity. The 
remaining one checks truncation on a date that is represented as a signed 
32bit quantity, but a negative one.

My AIX problem appears to be simply that mktime() won't countenance any time 
before 1970-1-1 or after 2038-1-19. In other words, it won't generate a time_t 
that is not a positive, signed 32bit quantity (Python throws OverflowError). 
Personally, I reckon refusing to generate a date between 1901-12-13 and 
1970-1-1 is a bit broken. That being the case, treating it as a bit of AIX 
badness (and having the AIX flag available for other future cases of AIX 
badness) seemed a reasonable approach.

The test Thomas deleted checked for wrap-around in a date after 2038-1-19. It 
seems more reasonable to me for a 32bit system to reject a date that can't be 
represented as a signed 32bit quantity. 32bit Debian does this - again, Python 
throws OverflowError. Rather weirdly, 64bit Debian rejects dates before 
1901-12-13, throwing ValueError, but is happy with dates far into future - I 
got bored at year 4000.

Having now thought about it for a while, I've come to the conclusion that the 
remaining test is sufficient. It checks that timestamps are truncated to 31bits 
before comparing, which is the intention of the code. Reintroducing the future 
date test and having a single mktime() guard would mean neither test could be 
run on 32bit Linux, and I guess a lot of other 32bit OS, which seems a bad 
idea. Introducing a further guard to bring back an unnecessary test doesn't 
seem too clever either.

So I think this boils down to whether we treat AIX mktime()'s refusal to 
generate a negative 32bit time as AIX specific or potentially more widespread 
problem. In the absence of any evidence to the contrary, I suggest going with 
AIX specific for now is reasonable. Though I'd be more than happy to redo the 
patch with a -ve mktime() guard should that be the concensus.

Patch

diff -r f01a351db791 -r 8c560ad1cdc4 tests/hghave.py
--- a/tests/hghave.py	Fri Apr 26 01:12:03 2013 +0900
+++ b/tests/hghave.py	Tue Apr 30 14:56:33 2013 +0100
@@ -274,6 +274,9 @@ 
 def has_msys():
     return os.getenv('MSYSTEM')
 
+def has_aix():
+    return sys.platform.startswith("aix")
+
 checks = {
     "true": (lambda: True, "yak shaving"),
     "false": (lambda: False, "nail clipper"),
@@ -314,4 +317,5 @@ 
     "unix-permissions": (has_unix_permissions, "unix-style permissions"),
     "windows": (has_windows, "Windows"),
     "msys": (has_msys, "Windows with MSYS"),
+    "aix": (has_aix, "AIX"),
 }
diff -r f01a351db791 -r 8c560ad1cdc4 tests/test-dirstate.t
--- a/tests/test-dirstate.t	Fri Apr 26 01:12:03 2013 +0900
+++ b/tests/test-dirstate.t	Tue Apr 30 14:56:33 2013 +0100
@@ -55,8 +55,9 @@ 
 
 Test modulo storage/comparison of absurd dates:
 
+#if no-aix
   $ touch -t 195001011200 a
   $ hg st
   $ hg debugstate
   n 644          2 2018-01-19 15:14:08 a
-
+#endif