bug in x86/uclibc busybox touch
rob at landley.net
Sun Jan 2 13:25:06 UTC 2011
On Thursday 30 December 2010 21:50:57 Denys Vlasenko wrote:
> On Thursday 30 December 2010 03:32, Rob Landley wrote:
> > On Tue, Dec 28, 2010 at 7:45 PM, Denys Vlasenko
> > <vda.linux at googlemail.com> wrote:
> > > On Thursday 16 December 2010 13:54, Natanael Copa wrote:
> > >> $ touch -t 0001010000 moo
> > >> touch: invalid date '0001010000'
> > >>
> > >> the above works with coreutils touch and interestingly enough, with
> > >> x86_64 uclibc busybox
> > >
> > > Because 1900-01-01 is a negative Unix time which doesn't fit
> > > into 32-bit long.
> > A 64 bit target shouldn't have the "year 2038" problem. Midnight
> > January 1 1970, plus or minus 68 years and change.
> > > "busybox touch -t 0112130000 file" works,
> > > and sets t=-2147475600 (0x80001f70).
> > >
> > > Previous day, -t 0112130000, doesn't.
> > If you ls -l the file "moo" after creating it above, its date is
> > 01-01-2000. Not 1900.
> In busybox touch, it will be 19xx (on 64-bit machines,
> where date 1900-01-01 fits into time_t).
It turns out SUSv4 specifies this:
69-99 is prefixed with "19", 00-68 is prefixed with 20. (That way, it never
creates a negative epoch.)
Personally, I'd do something based on the current year, say accept
"current-60" into the past and "current+40" into the future, since there's a
bias for historical dates over future dates. But if SUSv4 is going to insist
on hardcoding in a new Y2K variant, that's its' stupid perogative.
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem
Forever, and as welcome as New Coke.
More information about the busybox