Date: Fri, 26 Oct 2001 18:51:33 -0700 From: Peter Wemm <peter@wemm.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Dag-Erling Smorgrav <des@ofug.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <20011027015133.E4539380A@overcee.netplex.com.au> In-Reply-To: <200110270137.f9R1bVv06321@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: > If there is a shift in the time_t paradigm, it's going to need to be > driven by the industry at large, and it will need to be supported by > wider consensus than a small frothing cabal such as currently stands > behind this set of proposals. Does "Linux" represent a large enough portion of the Unix industry? Its 64 bit platforms have 64 bit time_t (long) and their 32 bit platforms have 32 bit time_t (long). We have new 64 bit platforms coming online as we speak. It would be a terrible shame to waste the opportunity to resolve it. Unlike the others in the thread, I see little benefit but lots of pain, in changing time_t on i386. I doubt i386 32 bit apps will be around in 20 years. If it lives on, it will be something like x86-64 or intel's spin on that. It too will have 64 bit "long" and we can use a 64 bit time_t there. I dont see sufficient reason to inflict this pain on i386 in the name of having the same size time_t. Having the same type (long) - yes, but using a quad_t is just expensive overkill. I wish I hadn't even brought up the possibility of changing i386. I didn't make it clear enough how much I hated the idea of it. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011027015133.E4539380A>