[Dropping libc-alpha from CC]
Hi Paul,
> I was thinking of something more ambitious: having Gnulib support 64-bit
> time_t on
> 32-bit glibc now, even before the Glibc support is in. In doing this, it
> would
> emulate the planned Glibc behavior by defining the Glibc macro's name (even
> though the underlying Glibc doesn't use the macro yet).
AFAICS, doing this for mktime, strftime, strptime would be moderately easy.
But for gettimeofday, stat, fstat, we would need to use the appropriate
Linux kernel system calls, which is
1. not trivial (especially redefining 'struct stat' is hairy),
2. soon to be contained in glibc anyway (and such code which interfaces
with the kernel belongs in glibc I'd say).
What would be the benefit of doing so in gnulib? That some, but not all,
programs of a Linux distro can claim Y2038-proof-ness before all the rest?
Is that worth it?
Bruno
