Re: Anybody involved with ISO C standardization ?

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