Re: Y2038 (was: Re: Userapi, Reflection)

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Tue, 4 Nov 2003 11:46:38 -0800 (PST)
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:

> 
> :On Tue, 4 Nov 2003 10:18:01 -0800 (PST)
> :Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
> :
> :>    What I would also like to do is 'fix' system calls which return
> structures,:>    like gettimeofday(), fstat(), and so forth... instead
> of returning:>    structures they would return a resource array.  The
> personality code:>    would then scan the resource array to load the C
> structures that the user:>    program expects.
> :
> :Ah, speaking of which, are there any plans to address the Y2038 bug
> in DFBSD?:
> :This mechanism would be an excellent first step towards it.
> :
> :-Chris
> :(singing the Beatles' "When I'm 64" :)
> 
>     This has been discussed many times on the FreeBSD lists.  The
>     FreeBSD folks would prefer to simply wait for all architectures to
>     become 64 bits. e.g. for IA32 to die out.  I would prefer to make
>     time_t a 64 bit quantity.  But both 'solutions' have serious
>     problems.  time_t is assumed to be a 'long' in a great deal of
>     third party code.
> 
>     Another alternative would be to create a new 64 bit API or to
>     supply a compiler option that allows time_t to be 64 bits for
>     those programs that won't barf on 64 bit time_t's.

Hmm, maybe I misunderstood the thrust of the thread.  Wouldn't it be
possible (indeed, desirable) to store the time internally as a
struct tai (or whatever) and have the 'personality module' translate it
on demand for programs that expect a signed-32-bit-seconds-since-1970?

Granted, the programs themselves would still be Y2038-broken... but if
the operating system isn't, they really have no excuse - and the process
of healing them could begin.

Unless, of course, I seriously misunderstand one or both of the issues
involved, which is very possible.

-Chris