Re: Y2038 - best way forward in Debian?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>  * 32-bit ABIs/arches are more awkward. glibc will continue *by
>    default* to use 32-bit time_t to keep compatibility with existing
>    code. This will *not* be safe as we approach 2038.
>
>  * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
>    upwards, but this will of course affect the ABI. Embedded uses of
>    time_t in libraries will change size, etc. This *will* be safe for
>    2038.

And that's chosen at build time (i.e. when compiling glibc)?
Why not provide different entry points for time-manipulating functions,
so a single build can support both applications using 32bit time and
applications using 64bit time?

E.g.

    struct time32_t ...
    struct time64_t ...

    double difftime32 (time32_t time1, time32_t time0);
    double difftime64 (time64_t time1, time64_t time0);

and in the time.h have

    #if TOO_OLD_TO_LIVE_PAST_2038
    typedef time32_t time_t;
    ...
    #else
    typedef time64_t time_t;
    ...
    #endif


-- Stefan