Date: Sat, 27 Oct 2001 16:07:23 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: dillon@apollo.backplane.com Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 Message-ID: <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> In-Reply-To: <200110271706.f9RH6ga47601@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <200110271706.f9RH6ga47601@apollo.backplane.com> you write: [quoting Peter Wemm] >:But that the idea of it still gives me the creeps. I believe we'll be >:chasing bugs from this for years on the i386. For what it's worth, I agree strongly with Peter. Perhaps more than strongly; I think it's absolutely insane to even contemplate changing time_t on IA-32 over the course of anything less than a decade. Times *are* that critical. > I think the absolute worst that can happen is that moving time_t to > 64 bits will have the same sort of impact on ports that moving off_t to > 64 bits had. Not so. You've missed one extremely important issue: off_t was not passed by reference in any standard interface. Indeed, it was a new invention only a few years old. time_t is passed by reference in all standard interfaces except mktime(). Furthermore, many other systems had longer-than-long off_t (that's what the whole Large File Summit thing was about); there are NO other systems which have longer-than-long time_t. In those systems, which actually cared about standards compliance, the *32/*64 and EOVERFLOW hacks introduced by the LFS were used so that standard-compliant applications would not break. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick 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?200110272007.f9RK7NG88372>