[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mercurial-devel
Subject:    Re: [PATCH] tests: AIX can't handle negative date in test-dirstate.t
From:       Jim Hague <jim.hague () acm ! org>
Date:       2013-04-30 23:21:46
Message-ID: 201305010021.46337.jim.hague () acm ! org
[Download RAW message or body]

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.
-- 
Jim Hague - jim.hague@acm.org          Never trust a computer you can't lift.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@selenic.com
http://selenic.com/mailman/listinfo/mercurial-devel
[prev in list] [next in list] [prev in thread] [next in thread]