>If it was a matter of making a single variable do something like that,
>it could be hacked in. but we're talking about a commonly used data
>type. I dont see this as possible for such a datatype.
>As someone else said before, the problem is not moving the type to 64
>bit. Most apps wont mind this at all. But what about apps which assume
>that this type is 32-bit? for example, what if someone is using time_t
>as a direct timestamp in a tightly structured network packet or
>something? That is the main issue.
Thank you for your comments.
First of all,this solution in intended to make the current programs work
without recompilation _only till 2038_ as well as support a 64 bit
version of time_t for programs which need to be recompiled urgently
to support dates beyond 2038.
This does involve writing new syscalls or wrappers.
As you said, time_t is a commonly used datatype.Exactly that is why
we have to let time_t remain in the kernel and overlay l_time_t on it.
Had it not been a commonly used variable then it would have been
a simple change in 'time.h' without any overlaying.
The overlaying will prevent breaking of programs which use time_t .
Let us consider a scenario before yr 2038 in which the overlaying
is done on the kernel's instance of time_t (in the instance of the
'timespec' struct if i am not wrong) and we also have an instance
of l_time_t in the kernel.
If a user program uses a function say ctime() which returns a time_t
variable,then the function will continue to work well, as the kernel
will return the value from its instance of time_t.
The change in the kernel is transparent to the user and also to the
syscall which gets the number of seconds.Since we have done
link-time alterations (overlaying) no code has changed.
On the other hand if we wished to use the l_time_t in a program
then we will have to create a new syscall to read the 64 bit value
and return it.Now we can get the 64 bit value from a function
say l_time() and assign it to a l_time_t variable in our
program.
The solution consists only of addtions to the kernel code and
no removals, so hopefully older programs will work without
recompilation.
>bit. Most apps wont mind this at all. But what about apps which assume
>that this type is 32-bit? for example, what if someone is using time_t
>as a direct timestamp in a tightly structured network packet or
>something? That is the main issue.
The apps which assume a 32 bit value and are correctly working now
will also continue to work even after the change in the kernel.If we
completely abolish 32 bit time_t and bring in a 64 bit version then such
assumptions would become void.
Ofcourse,such programs and the protocols used by them will have to be
changed to work after 2038.
Hope i have not overlooked (m)any important facet(s) :)
Regards,
Pranav.
--
______________________________________________________________________
Pune GNU/Linux Users Group Mailing List: (plug-mail@plug.org.in)
List Information: http://plug.org.in/mailing-list/listinfo/plug-mail
Send 'help' to [EMAIL PROTECTED] for mailing instructions.
