From owner-freebsd-current@FreeBSD.ORG Fri Mar 19 06:08:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77E1116A4CE for ; Fri, 19 Mar 2004 06:08:25 -0800 (PST) Received: from hermes.aueb.gr (hermes.aueb.gr [195.251.255.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71AD543D39 for ; Fri, 19 Mar 2004 06:08:24 -0800 (PST) (envelope-from dds@aueb.gr) Received: from aueb.gr (faculty05.wrong.dialup.aueb.gr [195.251.251.249]) by hermes.aueb.gr (8.12.9/8.12.9) with ESMTP id i2JE7i3g031521; Fri, 19 Mar 2004 16:07:45 +0200 Message-ID: <405AAC1A.20408@aueb.gr> Date: Fri, 19 Mar 2004 10:15:22 +0200 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, el, de MIME-Version: 1.0 To: Craig Boston References: <200403140716.i2E7GDKa007204@dungeon.home> <200403142317.09065.craig@xfoil.gank.org> In-Reply-To: <200403142317.09065.craig@xfoil.gank.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Garance A Drosihn cc: Stephen McKay Subject: Re: HEADS UP! MAJOR change to FreeBSD/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 14:08:25 -0000 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