Date: Fri, 19 Mar 2004 10:15:22 +0200 From: Diomidis Spinellis <dds@aueb.gr> To: Craig Boston <craig@xfoil.gank.org> Cc: Stephen McKay <smckay@internode.on.net> Subject: Re: HEADS UP! MAJOR change to FreeBSD/sparc64 Message-ID: <405AAC1A.20408@aueb.gr> In-Reply-To: <200403142317.09065.craig@xfoil.gank.org> References: <p060204f5bc750679b827@[128.113.24.47]> <200403140716.i2E7GDKa007204@dungeon.home> <p06020404bc7abad600b6@[128.113.24.47]> <200403142317.09065.craig@xfoil.gank.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Craig Boston wrote: [...] > The biggest problem on i386 is that there's a lot of third party software out > there that misbehaves if sizeof(time_t) > sizeof(long), even when recompiled > from source. I don't think this an issue on sparc64/amd64 -- IIRC long is > already 64 bits on those platforms. Only real solutions I can think of at > the moment are: [...] > 2. Bite the bullet and fix all the broken software. This is probably the > 'correct' approach. I don't know exactly which specs (POSIX? C99?) apply, > but I'm under the impression that no guarantee is made about the size of > time_t relative to other basic types. If someone knows for sure, please > correct me. I am copying from ISO/IEC 9899:1999, section 7.23.1: "The types declared are size_t; clock_t and time_t which are arithmetic types capable of representing times" [...] "The range and precision of times representable in clock_t and time_t is implementation-defined." So, indeed there is no guarantee made regarding the size of time_t relative to other basic types. However, time_t must be an arithmetic type, it can not be e.g. a struct. Another interesting possibility that the standard appears to allow, is to change the *precision* of time_t. For example, if time_t represented time in two-second intervals we shift the manifestation of the problem to the year 2106. Unforunatelly, this would affect the same programs that would be affected from the values 2**31 - (2**32 - 2) for representing time: those that are not using difftime and double for calculating and storing time differences. Diomidis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?405AAC1A.20408>