From owner-freebsd-arch Sat Oct 27 13: 7:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 04F0637B403 for ; Sat, 27 Oct 2001 13:07:26 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9RK7NG88372; Sat, 27 Oct 2001 16:07:23 -0400 (EDT) (envelope-from wollman) Date: Sat, 27 Oct 2001 16:07:23 -0400 (EDT) From: Garrett Wollman Message-Id: <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> To: dillon@apollo.backplane.com Subject: Re: time_t not to change size on x86 In-Reply-To: <200110271706.f9RH6ga47601@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> Organization: MIT Laboratory for Computer Science Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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