Date: Mon, 4 Jun 2001 02:23:13 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: obrien@FreeBSD.ORG, Matt Dillon <dillon@earth.backplane.com>, David Wolfskill <david@catwhisker.org>, arch@FreeBSD.ORG Subject: Re: time_t definition is worng Message-ID: <Pine.BSF.4.21.0106040213160.50121-100000@besplex.bde.org> In-Reply-To: <39981.991511499@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2 Jun 2001, Poul-Henning Kamp wrote: > In message <20010602124732.F31257@dragon.nuxi.com>, "David O'Brien" writes: > >On Sat, Jun 02, 2001 at 10:39:09AM -0700, Matt Dillon wrote: > >> Consistency is best, but breaking IA32 to match the already broken > >> Alpha port is the wrong solution. For consistency we should match > > > >Why is the Alpha port broken? time_t is 32-bits without question. Thus > >it must be an `int' on Alpha, IA-64, and sparc64. > > Uhm, time_t must be signed and at least 32 bits. No. In practice, it must be precisely 32 bits (but possibly unsigned) since it is used in ffs's super block and cylinder groups (but not directly in ffs's inodes - they use int32_t and it is assumed that time_t's fit in int32_t). In theory, it can be any signed arithmetic type from signed char to long double (in C90, more in C99). Some types can't be used in practice because they are too small or too unsuitable. > It would be neat > if all platforms had it longer than 32 bits in the next decade > some time. This would mainly be a small pessimization. > >> Certain core types like time_t > >> have serious limitations when declared as a fixed width type (int > >> nowadays). long is the perfect solution and you just blew that all to > >> hell with this commit. > > > >I am more than willing to define time_t as `long long' so it is 64-bits > >across the board. > > We'll have to do this before 2038 anyway... You mean "before 2106". uint32_t can represent times between 1970 and 2106. If you want to represent times much before 1970, then time_t is already inadequate. Bruce 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?Pine.BSF.4.21.0106040213160.50121-100000>