Jeff King p...@peff.net writes:
On Fri, Mar 28, 2014 at 12:30:02PM -0700, Junio C Hamano wrote:
Let's just deal with a simple known cases (like FreeBSD) in the real
code that everybody exercises at runtime, and have the new test only
check we do not segfault on a value we used to segfault
On Tue, Apr 01, 2014 at 12:07:22PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Mar 28, 2014 at 12:30:02PM -0700, Junio C Hamano wrote:
Let's just deal with a simple known cases (like FreeBSD) in the real
code that everybody exercises at runtime, and have the
Jeff King p...@peff.net writes:
Sat Jan 25 10:46:39 316889355 -0700
9 Wed Sep 6 02:46:39 -1126091476 -0700
99 Thu Oct 24 18:46:39 1623969404 -0700
Thanks. Given the value where it fails, it kind of looks like there is
some signed 32-bit value
On Fri, Mar 28, 2014 at 09:41:53AM -0700, Junio C Hamano wrote:
Offhand, the three possible failure modes this thread identified
sounds to me like the only plausible ones, and I think the best way
forward might be to
- teach the is the result sane, even though we may have got a
Jeff King p...@peff.net writes:
On Fri, Mar 28, 2014 at 09:41:53AM -0700, Junio C Hamano wrote:
Offhand, the three possible failure modes this thread identified
sounds to me like the only plausible ones, and I think the best way
forward might be to
- teach the is the result sane, even
On Fri, Mar 28, 2014 at 12:02:46PM -0700, Junio C Hamano wrote:
- teach the is the result sane, even though we may have got a
non-NULL from gmtime? otherwise let's signal a failure by
replacing it with a known sentinel value codepath the new
failure mode Charles's report
Jeff King p...@peff.net writes:
This (non-)issue has consumed a lot more brain power than it is probably
worth. I'd like to figure out which patch to go with and be done. :)
Let's just deal with a simple known cases (like FreeBSD) in the real
code that everybody exercises at runtime, and have
On Wed, Mar 26, 2014 at 10:46:16PM +, Charles Bailey wrote:
On Wed, Mar 26, 2014 at 05:57:41PM -0400, Jeff King wrote:
Hmm, so the year you got is actually: 1623969404. That still seems off
to me by a factor 20. I don't know if this is really worth digging into
that much further, but I
One of the tests in t4212 checks our behavior when we feed
gmtime a date so far in the future that it gives up and
returns NULL.
But some gmtime implementations just refuse to quit. They
soldier on, giving us a glimpse of a chilly October evening
some 160 million years in the future (and
Jeff King p...@peff.net writes:
+cmp_one_of () {
+ for candidate in $@; do
Style ;-)
+ echo $candidate expect
+ test_cmp expect actual
+ return 0
+ done
+ return 1
+}
It actually may be easier to understand if you write a trivial case
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
That being said, is the AIX value actually right? I did not look closely
at first, but just assumed that it was vaguely right. But:
99 / (86400 * 365)
is something like 31 billion years in the future, not 160
On Wed, Mar 26, 2014 at 03:40:43PM -0400, Jeff King wrote:
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
That being said, is the AIX value actually right? I did not look closely
at first, but just assumed that it was vaguely right. But:
99 / (86400 * 365)
On Wed, Mar 26, 2014 at 08:36:18PM +, Charles Bailey wrote:
On Wed, Mar 26, 2014 at 03:40:43PM -0400, Jeff King wrote:
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
That being said, is the AIX value actually right? I did not look closely
at first, but just assumed
On Wed, Mar 26, 2014 at 04:38:30PM -0400, Jeff King wrote:
By the way, can you confirm that this is a 64-bit system? On a 32-bit
system, we should be triggering different code paths (we fail at the
strtoul level). Those should be checked by the previous tests, but I'd
like to make sure.
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
That being said, is the AIX value actually right? I did not look closely
at first, but just assumed that it was vaguely right. But:
99 / (86400 * 365)
is something like 31 billion years in the future, not 160
On Wed, Mar 26, 2014 at 09:22:27PM +, Charles Bailey wrote:
On Wed, Mar 26, 2014 at 03:33:59PM -0400, Jeff King wrote:
That being said, is the AIX value actually right? I did not look closely
at first, but just assumed that it was vaguely right. But:
99 / (86400
On Wed, Mar 26, 2014 at 05:57:41PM -0400, Jeff King wrote:
Hmm, so the year you got is actually: 1623969404. That still seems off
to me by a factor 20. I don't know if this is really worth digging into
that much further, but I wonder what you would get for timestamps of:
9
17 matches
Mail list logo
