Date: Fri, 26 Oct 2001 19:49:36 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, arch@FreeBSD.ORG, Peter Wemm <peter@wemm.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Bakul Shah <bakul@bitblocks.com>, Mike Smith <msmith@FreeBSD.ORG>, Dag-Erling Smorgrav <des@ofug.org> Subject: Re: 64 bit times revisited.. Message-ID: <3BDA20C0.ED922810@mindspring.com> References: <XFMail.011026181705.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > You did read the e-mail from Garrett where either SUS or POSIX one requires > time_t to fit in a long? I.e. sizeof(time_t) <= sizeof(long). The basis for this is the atomic type argument. We already violate this one (in spades) for the off_t definition, which has the same requirement, yet is a "long long" on FreeBSD. Just food for thought... if the standard doesn't cover the case, it doesn't automatically mean that compliance is a good idea. We could always hack the compiler for an 128 bit "atomic" type, e.g. "very long long" or "long long long", and treat time_t the same way we treat off_t: with a nod and a wink to the standard, but incomplete actualtechnical compliance, if you were a C language lawyer... -- 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?3BDA20C0.ED922810>