Date: Thu, 26 Feb 2004 15:47:02 -0500 From: Ken Smith <kensmith@cse.Buffalo.EDU> To: John Polstra <jdp@polstra.com> Cc: freebsd-sparc64@freebsd.org Subject: Re: 64btt cvsup? Message-ID: <20040226204702.GA8602@electra.cse.Buffalo.EDU> In-Reply-To: <XFMail.20040226122033.jdp@polstra.com> References: <p06020487bc61aea919fe@[128.113.24.47]> <XFMail.20040226122033.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 26, 2004 at 12:20:33PM -0800, John Polstra wrote:
> <ADVICE COST=0>
Advice greatly appreciated.
> All of a sudden, without any warning, the time() call is likely to
> start scribbling a 0 into either "a" or "b" -- or, worse yet, into
> half of the return address or frame pointer. Who knows what the
> symptoms of that will be? Will they be deterministic? Will they
> cause ugly security vulnerabilities? Whee!
I think this is why we might be able to get away with not providing
the compatibility stuff - this part isn't quite true. Users can't
do a normal upgrade path (cvsup to -current, make buildworld/etc)
and get to a 64-bit time_t system. If you try to do an upgrade through
the normal path you break your machine at that point. To make it to
a 64-bit time_t system without breaking your system you need to follow
Garance's instructions and use his tools to do the upgrade. So there
kinda is a warning.
Does that help any, or is this still a huge mistake?
--
Ken Smith
- From there to here, from here to | kensmith@cse.buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040226204702.GA8602>
