You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Alvaro Martinez Echevarria <al...@lander.es> on 1998/06/07 05:26:43 UTC
time_t is 64 bits in linux/alpha
On Fri, 5 Jun 1998, Dean Gaudet wrote:
> Is time_t 64-bits on alpha-linux ?
> Dean
Yes, as defined by /usr/include/asm/posix_types.h:
typedef long __kernel_time_t;
and /usr/include/linux/types.h:
typedef __kernel_time_t time_t;
So it's 64 bits. Right now I'm working on a patch for
mod_unique_id to fix this problem, and to make it more simple I
have changed the type of stamp from "time_t" to "unsigned int".
This way htonl and ntohl work properly (although we'll have to
change this back to 64bits before year 2106).
Probably I'll submit the patch in a few minutes.
Regards.
.------------------------------------------------------------------.
| Alvaro Martínez Echevarría | LANDER SISTEMAS |
| alvaro@lander.es | Pº Castellana, 121 |
`--------------------------------| 28046 Madrid, SPAIN |
| Tel: +34-91-5562883 |
| Fax: +34-91-5563001 |
`---------------------------------'
Re: time_t is 64 bits in linux/alpha
Posted by Dean Gaudet <dg...@arctic.org>.
Er, yeah you guys are right, my head wasn't working correctly. Alvaro
pointed out the thing I was forgetting :)
Dean
On Sun, 7 Jun 1998, Alvaro Martinez Echevarria wrote:
> I'm probably missing something here. If your server timestamps go from
> 32-bit to 64-bit, uuencoded tokens will grow 5 characters (from
> 19 to 24); so tokens will be unique anyway, won't they?
> Regards.
On Sun, 7 Jun 1998, Ben Laurie wrote:
> 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.
Re: time_t is 64 bits in linux/alpha
Posted by Ben Laurie <be...@algroup.co.uk>.
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/
Re: time_t is 64 bits in linux/alpha
Posted by Alvaro Martinez Echevarria <al...@lander.es>.
On Sat, 6 Jun 1998, Dean Gaudet wrote:
> 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:
I'm probably missing something here. If your server timestamps go from
32-bit to 64-bit, uuencoded tokens will grow 5 characters (from
19 to 24); so tokens will be unique anyway, won't they?
Regards.
.------------------------------------------------------------------.
| Alvaro Martínez Echevarría | LANDER SISTEMAS |
| alvaro@lander.es | Pº Castellana, 121 |
`--------------------------------| 28046 Madrid, SPAIN |
| Tel: +34-91-5562883 |
| Fax: +34-91-5563001 |
`---------------------------------'
Re: time_t is 64 bits in linux/alpha
Posted by Dean Gaudet <dg...@arctic.org>.
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.
Dean
On Sat, 6 Jun 1998, Dean Gaudet wrote:
> Yeah I was thinking about how to deal with this cleanly... it's too bad C
> doesn't define the result of "u >> 32" where u is 32 bits... because we
> could code it to expect a 64-bit time_t and break it into two parts, and
> for 32-bit time_t it would result in a bunch of dead code (eliminated at
> compile time).
>
> NSPR defines a 64-bit PRTime ... so it'll be easy to clean up in the nspr
> version.
>
> Dean
>
> On Sun, 7 Jun 1998, Alvaro Martinez Echevarria wrote:
>
> > On Fri, 5 Jun 1998, Dean Gaudet wrote:
> >
> > > Is time_t 64-bits on alpha-linux ?
> > > Dean
> >
> > Yes, as defined by /usr/include/asm/posix_types.h:
> >
> > typedef long __kernel_time_t;
> >
> > and /usr/include/linux/types.h:
> >
> > typedef __kernel_time_t time_t;
> >
> > So it's 64 bits. Right now I'm working on a patch for
> > mod_unique_id to fix this problem, and to make it more simple I
> > have changed the type of stamp from "time_t" to "unsigned int".
> > This way htonl and ntohl work properly (although we'll have to
> > change this back to 64bits before year 2106).
> > Probably I'll submit the patch in a few minutes.
> > Regards.
> >
> > .------------------------------------------------------------------.
> > | Alvaro Martínez Echevarría | LANDER SISTEMAS |
> > | alvaro@lander.es | Pº Castellana, 121 |
> > `--------------------------------| 28046 Madrid, SPAIN |
> > | Tel: +34-91-5562883 |
> > | Fax: +34-91-5563001 |
> > `---------------------------------'
> >
> >
>
>
Re: time_t is 64 bits in linux/alpha
Posted by Dean Gaudet <dg...@arctic.org>.
Yeah I was thinking about how to deal with this cleanly... it's too bad C
doesn't define the result of "u >> 32" where u is 32 bits... because we
could code it to expect a 64-bit time_t and break it into two parts, and
for 32-bit time_t it would result in a bunch of dead code (eliminated at
compile time).
NSPR defines a 64-bit PRTime ... so it'll be easy to clean up in the nspr
version.
Dean
On Sun, 7 Jun 1998, Alvaro Martinez Echevarria wrote:
> On Fri, 5 Jun 1998, Dean Gaudet wrote:
>
> > Is time_t 64-bits on alpha-linux ?
> > Dean
>
> Yes, as defined by /usr/include/asm/posix_types.h:
>
> typedef long __kernel_time_t;
>
> and /usr/include/linux/types.h:
>
> typedef __kernel_time_t time_t;
>
> So it's 64 bits. Right now I'm working on a patch for
> mod_unique_id to fix this problem, and to make it more simple I
> have changed the type of stamp from "time_t" to "unsigned int".
> This way htonl and ntohl work properly (although we'll have to
> change this back to 64bits before year 2106).
> Probably I'll submit the patch in a few minutes.
> Regards.
>
> .------------------------------------------------------------------.
> | Alvaro Martínez Echevarría | LANDER SISTEMAS |
> | alvaro@lander.es | Pº Castellana, 121 |
> `--------------------------------| 28046 Madrid, SPAIN |
> | Tel: +34-91-5562883 |
> | Fax: +34-91-5563001 |
> `---------------------------------'
>
>