On Tue, Apr 01, 2014 at 12:07:22PM -0700, Junio C Hamano wrote:
> Jeff King 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
Jeff King 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 upon see
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 upon seeing.
OK. Here it is, with
Jeff King 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 the new test
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
Jeff King 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 tho
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
>n
Jeff King 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 at w
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,
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:
>
> 99
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:
> >
> > 9
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
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 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 a
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 / (864
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 16
On Wed, Mar 26, 2014 at 03:25:36PM -0400, Jeff King wrote:
> > The primary thing you wanted to achieve by the "gmtime gave us NULL,
> > let's substitute it with an arbitrary value to avoid dereferencing
> > the NULL" change was *not* that we see that same arbitrary value
> > comes out of the syste
On Wed, Mar 26, 2014 at 12:18:25PM -0700, Junio C Hamano wrote:
> > + 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
> statement
Jeff King 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 cas
19 matches
Mail list logo
