httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
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



Ben Laurie            |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|
and Technical Director|Email: |
A.L. Digital Ltd,     |Apache-SSL author
London, England.      |"Apache: TDG"


View raw message