Re: NULL pointer dereference in tai64nlocal
Rick Myers <[email protected]> Thu, 12 Sep 2013 21:11:55 -0400
| Newsgroups | gmane.comp.djb.syslog |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Sep 12, 2013 at 07:05:24AM -0600, Charles Cazabon wrote: > Rick Myers <[email protected]> wrote: > > > Thus said [email protected] on Tue, 10 Sep 2013 18:56:58 +1000: > > > > > > > # echo @ | tai64nlocal > > > > Segmentation fault > > > > Apparently it's a signedness problem... > [...] > > Which can be "fixed" with... > > > > --- tai64nlocal.c~ 2013-09-12 04:56:24.145298692 -0400 > > +++ tai64nlocal.c 2013-09-12 04:56:47.576278760 -0400 > > @@ -52,6 +52,7 @@ > > nanosecs += u; > > } > > secs -= 4611686018427387914ULL; > > + secs = secs > 0 ? secs : 0; > > t = localtime(&secs); > > out(num,fmt_ulong(num,1900 + t->tm_year)); > > out("-",1); out(num,fmt_uint0(num,1 + t->tm_mon,2)); > > > > > > Resulting in... > > > > $ echo @ | tai64nlocal > > 1969-12-31 19:00:00.000000000 > > For what it's worth, this appears to be the same issue that Jeremy Fishman > reported in > <CAD7zAcs--iyq1cq2-muBHMA6KTPR4rUUN8SRG0bwcTFwRk49tw@mail.gmail.com> last > November. He'll be happy for the fix ;) Yes, I believe you're right, so it's not a sign problem after all. As Jeremy pointed out, localtime() returns NULL on the high end long before LONG_MAX (9223372036854775807) at 67768036191694800. (Here, at least.) I don't think I believe the time tai64nlocal returns just before that extreme though. 18446744071562069867-12-31 23:59:59.000000000 On the low end localtime() will reach down to -62167201438, which is sort of interesting. There, tai64nlocal returns: 0-01-01 00:00:00.000000000 Meanwhile the construct 'echo @ | tai64nlocal' is trying to get the time for -4611686018427387914, which is of course much earlier. -- If there is a wrong way to do something, I've probably done it.