DragonFly kernel List (threaded) for 2003-11
Re: Y2038 (was: Re: Userapi, Reflection)
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.
> :(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.