From owner-freebsd-arch Sat Oct 27 13:29:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B39C637B403 for ; Sat, 27 Oct 2001 13:29:19 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RKTIi56468; Sat, 27 Oct 2001 13:29:18 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 13:29:18 -0700 (PDT) From: Matthew Dillon Message-Id: <200110272029.f9RKTIi56468@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> 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 :off_t was not passed by reference in any standard interface. Indeed, :it was a new invention only a few years old. So? A pass-by-reference sizing problem is at least as bad as a pass-by-value sizing problem. C promotes char's and short's to ints when passing them as parameters, but it doesn't automatically promote anything to long int. :time_t is passed by reference in all standard interfaces except :mktime(). So? That's why we have to roll the syscalls and major library rev. Older binaries will still run just fine. :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 I think the discussion in regards to sizeof(time_t) > sizeof(long) is a valid one, but I don't see it as a show stopper. I had issues with 2038 15-20 years ago, I have issues with 2038 now. I am not going to wait until 2037 for the problem to be fixed. 5.0 is the perfect place to fix it, and it needs to be fixed for IA32 as well as for everything else because I'm fraggin sick and tired of people whining about it for two decades and not particularly interested in hearing more whining for the next two decades. If time_t can be a double, it damn well can be an int64_t. -Matt :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message