> We can have a longer time_t in time.h like : u64 l_time_t; > > I do not know much about the kernel internals but,we can (can we ? ) map > the l_time_t such that its lower 32 bits coincide with those of time_t. > Incrementing l_time_t will automatically increment time_t and vice-versa > normally till 2038. 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.
> > Using a union comes to mind,but a union will require '.' or '->' operator > to be used, which again invites recompilation. Hmm... Change all programs which use time_t to use a union. thats quite out of the question. 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. -- Sagar Gokhale -- ______________________________________________________________________ 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.
