Date: Sun, 28 Oct 2001 09:18:30 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, arch@FreeBSD.org Subject: Re: time_t not to change size on x86 Message-ID: <3BDC3DE6.9F282BC@mindspring.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :> If time_t can be a double, it damn > :> well can be an int64_t. > : > :No, it can't. RTFS. > > We are still waiting to see what both C90 and C99 say. As DES would > say, quote the standard. So far nothing I've heard prevents us from > being able to make time_t a 64 bit int on IA32. Garrett is right. In laymans terms, the standard says that time_t must be of a type that will result in atomic update during assignment, and that this type must be a standard defined type (which lets out the "long long" type). I have had technical and philosophical disagreements with Garrett before, but I can count the number of times I was right and he was wrong about a standard on the fingers of one hand. You do realize -- he's _on_ the committees, right? The _only_ way you could get around this and remain in conformance with C90 would be to change "long" to be 64 bits; C99 is another language, altogether; it's still not clear to me that "long long" will end up being an atomic type on all platforms; I expect that on an 80386 (as opposed to a Pentium), "long long" will be 32 bits, just like "int" and "long", or you still won't be allowed to use it for time_t. -- Terry 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?3BDC3DE6.9F282BC>