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.