Date: 18 Mar 2004 18:56:37 -0700 From: llewelly@xmission.com To: Garance A Drosihn <drosih@rpi.edu> Cc: "Wafa M. Hadidi" <wmmh@identd.net> Subject: Re: Updating sparc64 time_t, hostname not found Message-ID: <s3rad2dd2ga.fsf@xmission.xmission.com> In-Reply-To: <p0602043dbc7fde745c29@[128.113.24.47]> References: <40594A35.6060303@exeter.ac.uk> <200403190005.22811.wmmh@identd.net> <p0602043bbc7fce6c9a52@[128.113.24.47]> <200403190057.36638.wmmh@identd.net> <p0602043dbc7fde745c29@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Garance A Drosihn <drosih@rpi.edu> writes:
[snip]
> Programs only know the time_t they were compiled with, so you
> would need to recompile them to get a 64-bTT version. Besides,
> if you had a 32-bTT kernel with 64-bTT applications, then I
> suspect you would see timestamps VERY different than 1970.
> (I guess I could check that...).
[snip]
sparc is big-endian. Most significant bytes are stored at lower
addresses.
so - let's say we have this date:
Thu Mar 18 18:31:39 2004
In 64 bTT hex, it looks like this:
00 00 00 00 40 5a 4d ea
The bytes at the low addresses are all 0.
If a pointer points to this time_t, but is of type pointer to 32 bTT,
only the first 4 bytes of the value will be fetched from memory
when the pointer is dereferenced. Those first 4 bytes are all 0,
resulting in a date of Jan 1, 1970.
At least that's my reasoning - but endians always confuse me.
(also, 64 bTT might result in things being in such different places
that the pointers point to the wrong thing entirely - so, even if the
above reasoning is correct, it's only a possibility.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?s3rad2dd2ga.fsf>