lkml.org 
[lkml]   [2000]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: time_t size: The year 2038 bug?
In <38746547.E20D18B4@aarnet.edu.au> Glen Turner (glen.turner@aarnet.edu.au) wrote:
> Dominik Kubla wrote:

> As I said in a previous posting, on these platforms the path
> of least resistance would appear to be to wait for the C
> standard to define a standard type "long long", implement that
> in the C compiler as the non-standard type _long _long is on
> those machines now (a 64 bit integer, with overhead due to a
> 32 bit implementation), and define the base type of time_t
> from long or int to long long.

long long is in gcc for VERY long time. It's slow but AFAIK more or less
bug free in recent versions. Why we should wait for C standard approval ?

> This leads to C library version problems, but that appears to be
> unavoidable. A compatibility library isn't difficult to develop.
> It may be desirable to break things deliberately at some
> stage: a program running a 32 bit time_t against a compatibility
> C library will die as badly as a program running a 32 bit time_t
> against a real C library in 2038. But this is getting way
> ahead of ourselves.

Just one note: you can do this without introducing new library or relinking.
with help of GLibC's 2.1.x versioning ...

> Until ISO C9x is approved by most national standards bodies, and
> then implmented in gcc, there is very little that can be done
> without changing the size of long -- this would lead to even more
> issues than changing the size of time_t.

long long is implemented in gcc RIGHT NOW. You do not need full ISO C9x
to change time_t definition.

> It is reasonable to expect ISO C, support in gcc, and time_t's base
> type as long long on 32 bit architectures well within the next decade,
> still leaving plenty of time before 2038.

> I humbly suggest that this is a Linux 3.0 issue :-)

It may seems odd but I agree :-) Now since we do not need changed time_t
ASAP but since you can change GLibC's time_t definition without changing
kernel's time_t definition. And since most programs are linked with shared
version of GLibC it'll enough to change just kernel<->glibc interface when
kernel will be changed...




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.079 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site