From owner-freebsd-standards@FreeBSD.ORG Tue Oct 14 12:29:48 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABD5116A4B3; Tue, 14 Oct 2003 12:29:48 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 999DC43FBD; Tue, 14 Oct 2003 12:29:45 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id FAA16237; Wed, 15 Oct 2003 05:29:29 +1000 Date: Wed, 15 Oct 2003 05:28:08 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Harti Brandt In-Reply-To: <20031014103446.U45269@beagle.fokus.fraunhofer.de> Message-ID: <20031015045429.Q41837@gamplex.bde.org> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014103446.U45269@beagle.fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@FreeBSD.org cc: sparc64@FreeBSD.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 19:29:48 -0000 On Tue, 14 Oct 2003, Harti Brandt wrote: > On Tue, 14 Oct 2003, Bruce Evans wrote: > > BE>On Mon, 13 Oct 2003, Harti Brandt wrote: > BE> > BE>> I just discovered that time_t is 32-bit on sparc64. One of the problems > BE>> is that struct timeval is defined by Posix as > BE>> > BE>> struct timeval { > BE>> time_t tv_secs; > BE>> suseconds_t tv_usecs; > BE>> }; > BE> > BE>This is a bug in POSIX. In BSD, tv_secs has type long which may be, > BE>and is different from time_t. > > Why do you think this is a POSIX bug? Aren't we the odd man out? Now we AFAIK (not all that far), timevals (or at least most of the things POSIX uses them for) are BSD things, so POSIX is broken since it is incompatable with the a reference implementation if not _the_ reference implementation. POSIX uses timevals mainly for getrusage(), select(), itimers, get/settimeofday(), utimes() and struct utmpx. All of these except utmpx are documented in the FreeBSD man pages ias first appearing in 4.2BSD. FreeBSD doesn't even have struct utmpx. It has struct utmp, which is documented as first appearing in V6. It is not quite compatible with V6 here and has actually regressed with respect to storing times: it uses "int32_t ut_time", but V7 uses "long ut_time". This regression occurred for binary compatibility reasons in FreeBSD (Lite2 uses "long ut_time"). > (and MacOS 10) require a workaround for thinks like > > printf("%s", ctime(tv.tv_secs)); & > > which works perfect on other systems. > BE>[ffs changes] > BE>To change time_t to 64 bits, all in-use non-transient data structures > BE>need to be changed similarly. > > I guess we have to do this work before 2038, don't we? If we don't do it > before 5.2 we have to stick with this until 6.0. Correct? Yes. It is too late to change it for 5.n IMO. Every syscall that uses a time_t or a timeval would need to be duplicated. This would give a lot of compatibility cruft that would have to be supported forever if the transition is not carefully managed. We still haven't managed to drop cruft like olseek() (to support 32-bit off_t's) although the clean break in 4.4BSD should have made it unnecessary. Bruce