httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: time_t is 64 bits in linux/alpha
Date Sun, 07 Jun 1998 13:10:55 GMT
Dean Gaudet wrote:
> 
> Oh yeah, I wanted to rant about big-endian order (i.e. network order).
> 
> If you study the theory behind mod_unique_id's tokens you'll see that with
> a "flag second" (second, or longer interval, in which no requests are
> served and all software is simultaneously upgraded) you can change from
> one token format to another... provided you keep the time_t at the front.
> If the time_t were in little-endian format, this would work correctly
> regardless of the time_t size on any of the hosts involved (assuming it's
> at least 32-bits long).
> 
> But no... it's big-endian order...  To perform an upgrade from 32-bit time
> stamps to 64-bit timestamps, and maintain the property that tokens are
> unique for all time, we have to do something like this:
> 
>     __u32 time_low;
>     __u32 time_high;
> 
> Each half is in BE order (network order).  But the 64-bit aggregate is in
> a mixed little/big format.  What a waste.
> 
> If it was in little endian format to begin with we could just start using
> "__u64 time;" and it would require no special coding.

I don't understand what you mean. In what sense is time_t big-endian?
Surely this is just a function of how you represent it? The way it is
stored on any particular machine depends on architecture.

I also don't get why making it little-endian makes the situation any
better.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author     http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache/

WE'RE RECRUITING! http://www.aldigital.co.uk/recruit/

Mime
View raw message