Re: An experiment: 64-bit time_t on IA-32 (5.2-RC)

This is probably more appropriate on -hackers at this point, so I'm 
redirecting there.  Bcc current so interested parties know where to look.

I'm also changing my From: to my -hackers address, so don't be alarmed ;)

On Tuesday 23 December 2003 12:52 am, Peter Jeremy wrote:
> I don't recall that.  I notice time_t is 'long' on i386 so bde's
> ia32-with-64-bit-longs will also have 64-bit time_t.

That may be what I'm thinking of.

> Looks like I was wrong about the adjacent field being spare - it seems
> it _has_ been used for high-res timestamps since I looked last.

The discussion I did find mentioned that that field had been used for 
milliseconds or something.  Hopefully by 2038 there won't be too many UFS1 
filesystems left ;)

> I was thinking of a totally independent implementation - eg the
> algorithms in Edward M. Reingold's "Calendrical Calculations".
> Agreeing with FreeBSD on an iA64 or amd64 could just be common bugs.

Ahhhh, math :)  I'll try cooking something up and see how it turns out.  I'll 
also run those numbers through my trusty HP-48 and see what it thinks as 
well.

> >Right now I'm recompiling world again because I didn't notice that struct
> >timeval had long hard-coded for tv_sec :(
>
> gcc should be able to pick this up for you.

I'm not sure I understand...

Right now I'm really wishing I had gone ahead and implemented some compat 
functions in libc and the kernel so that old binaries would work.  Being 
without cvsup is no fun at all.  I tried to update ports using anoncvs, but 
that was slooooow and eventually died.

> This isn't true now on Alpha and SPARC so I thought they had all been
> ironed out.  You may still get bitten if sizeof(time_t) > sizeof(long).

I think that's exactly what's happening.  All the cases I've isolated so far 
involve trying to stuff a time_t into a long (or sometimes even an int!), so 
if sizeof(long) > sizeof(time_t) it wouldn't be a problem.

The kdelibs one is no fun.  There are a couple places in KDE where a time_t is 
stored in some sort of configuration object -- the interface is slightly 
reminiscent of the Windows registry.  The storage function is overloaded, so 
if I make sure there is one for long long it will be able to store it just 
fine no matter what the architecture.  Getting it out is trickier since you 
have to know ahead of time what the type is in order to call the correct 
retrieval function (readLongNum, readLongLongNum, etc.)

Currently I'm thinking about doing something like
#if sizeof(time_t) == sizeof(long)
#define readTimeTNum readLongNum
#elif sizeof(time_t) == sizeof(long long)
#define readTimeTNum readLongLongNum
...

but that's really ugly.  Surely there's a better way?

Craig