Anybody involved with ISO C standardization ?
Chuck Swiger
cswiger at mac.com
Fri Jan 21 11:39:27 PST 2005
Poul-Henning Kamp wrote:
> In message <41F1519C.1090600 at mac.com>, Chuck Swiger writes:
[ ... ]
>>Indeed. Some clever person might decide to power of two which was a multiple
>>of 8 or 16 or so, so that you don't even have to shift bits, and you end up
>>with something that resembles (struct timeval). An integral timer with a
>>resolution of 1 tick = 1 second has a lot going right for it.
>
> The problem is that if you use 32 bits, then 64 bits don't stretch far
> enough, and if you use 24 bits you don't get enough resolution.
>
> My personal preference would be
>
> struct {
> signed 64+ bits: integer part.
> unsigned 32+ bits: fraction part.
> }
I would agree with this completely. A timescale that used:
struct {
int64_t seconds;
u_int64_t fract;
}
...would have native alignment and be capable of representing any reasonable
time with excessive precision. If the hardware only updated 32-bits or so
worth of fractional second precision, that would be just fine, too.
I don't have any problems with a 64-bit representation which uses a 32-bit
unsigned seconds value being backwards compatible with a traditional 32-bit
time(3) (which is still good for another thirty years), but you do have point
that the range is too short.
But you could use 32 bits on backwards compatible seconds, 16 bits for a
fractional second value (down to tenths of milliseconds), a 16 bits for a
signed year value:
struct {
u_int32_t seconds;
u_int16_t fract;
int16_t year;
}
If year = 1970, seconds is equivalent to Unix epoch. Otherwise, the range is
big enough to handle calendars which have a non-Gregorian year and also fit
the 26,000 year precession of the earth's wobble of the celestial north pole.
:-)
--
-Chuck
More information about the freebsd-current
mailing list