From owner-freebsd-arch Fri Oct 26 19:34:34 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 C911837B409 for ; Fri, 26 Oct 2001 19:34:30 -0700 (PDT) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id f9R2YT777473; Fri, 26 Oct 2001 22:34:29 -0400 (EDT) (envelope-from wollman) Date: Fri, 26 Oct 2001 22:34:29 -0400 (EDT) From: Garrett Wollman Message-Id: <200110270234.f9R2YT777473@khavrinen.lcs.mit.edu> To: Bill Fenner Cc: arch@freebsd.org Subject: Re: 64 bit times revisited.. In-Reply-To: <200110270146.SAA16181@windsor.research.att.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> <200110262209.f9QM9on75561@khavrinen.lcs.mit.edu> <200110270146.SAA16181@windsor.research.att.com> 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 < said: > The types declared [in ] are ... clock_t and time_t which are > arithmetic types capable of representing times. > Are you saying that C90 has an explicit requirement that time_t can't > be longer than 'long', or simply that C90 didn't have any types longer > than 'long'? Yes. C90 did not define any arithmetic types other than float, double, {signed,unsigned,} char, and {signed,unsigned} {short,long,} int. A later interpretation against C90 (requested by Clive Feather, IIRC) made it explicit that every typedef in the standard must resolve to a specific standard type of the indicated classification(s). C99 relaxes this requirement somewhat, by allowing additional arithmetic types, and by providing a new mechanism (intmax_t and the `j' format modifier) in which every implemented integral type is supported as a subset. Because C90 did not place any stricter requirement on time_t than that it be arithmetic, the POSIX review group did not feel it was necessary to further constrain the definition when aligning POSIX to C99; in essence, if a programmer was already prepared for time_t to be a long double, as required by the standard, then no additional work is needed if time_t is a long long or even a __fixpt128_t. However, the POSIX definition of ``seconds since the epoch'' implies an integer value, not floating-point, and even though the standard does not constrain time_t to be integer, almost all programs assume that it is. Thus, a C90 program which makes this assumption may fail if time_t is a new C99 type. For important POSIX types which were integers, the Austin group generally added a restriction to C90 types, in order to facilitate portability of programs from 1003.1-1996 and SUSv2, which did not have intmax_t or `j' formats, to the new standard (1003.1-2001) which does. For these reasons, I submit that FreeBSD should likewise not pull the rug out from under programmers who had no reason to ever expect time_t to be longer than a long (which, keep in mind, is the historical type going back to Seventh Edition UNIX). I've heard a lot of ``well, 5.0 is going to be such a huge leap that one more big change won't hurt so bad''. I disagree. I think 5.0 is already such a huge leap that many people will have a strong disincentive to adopt it at all, and every time we make that transition harder, more people will jump *off* the bandwagon. We already have several important, even revolutionary changes in the pipeline. But, if we continue to stage a revolution every quarter, 5.0 will never be shippable. This isn't to say that the groundwork can't be laid; I would not be opposed to seeing the kernel-internal timekeeping API improved with support for wider time_ts, and certainly we should update the filesystems and other important supporting infrastructure, but I don't believe that types should be changed on any existing platforms. It took five years to finally get rid of ; the assumption that |time_t| <= |long| is far more deeply in-grained in third-party software than ever was. (Which is why POsIX always has a huge flamefest at every revision about ``fixing'' the definition of Seconds Since the Epoch.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message