Date: Fri, 26 Oct 2001 22:34:29 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Bill Fenner <fenner@research.att.com> Cc: arch@freebsd.org Subject: Re: 64 bit times revisited.. Message-ID: <200110270234.f9R2YT777473@khavrinen.lcs.mit.edu> In-Reply-To: <200110270146.SAA16181@windsor.research.att.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> <p0510101ab7ff49f3b996@[128.113.24.47]> <200110262151.f9QLp1b75389@khavrinen.lcs.mit.edu> <200110262209.f9QM9on75561@khavrinen.lcs.mit.edu> <200110270146.SAA16181@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Fri, 26 Oct 2001 18:46:52 -0700, Bill Fenner <fenner@research.att.com> said:
> The types declared [in <time.h>] 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 <malloc.h>; the assumption that
|time_t| <= |long| is far more deeply in-grained in third-party
software than <malloc.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110270234.f9R2YT777473>