Date: Fri, 18 Nov 2005 07:01:40 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Axel Gonzalez <loox@e-shell.net> Cc: freebsd-amd64@FreeBSD.org Subject: Re: nasty amd64 date bug? Message-ID: <20051118055837.W96399@delplex.bde.org> In-Reply-To: <200511171026.08194.loox@e-shell.net> References: <28edec3c0511170534n14586426vd7cee0115e45b58c@mail.gmail.com> <200511171026.08194.loox@e-shell.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Nov 2005, Axel Gonzalez wrote: > $ date -r 190300000000 > Sun May 14 01:06:40 CST 8000 > > This is probably a bios error, that can't handle dates so much in the future > > This happens only on amd64, because it uses 64 bits utimes. amd64 has 64 bit time_t's. There are no utimes here. > On i386, with 32 bits utimes, the maximun date is about 2032, so the bios > shouldn't have problems with that date (remember the *nix version of the y2k > problem ??) This shows that 64-bit time_t's don't actually work. Probably something is looping about 190000000000 times. There used to be such a loop in kern_tc.c. This loop still has overflow bugs in its sanity checking (see rev.1.156) but these only reduce the amount of looping for steps larger than INT_MAX and increase it from 0 iterations to at most LARGE_STEP = 200 iterations for steps smaller than INT_MAX. > So this is not really a bug, is a feature ;) Nah. [Context lost to top posting.] Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051118055837.W96399>