3 ms·

I think it lets developers opt-in to fixing their glibc-dependent programs ahead of time, so there's less work to do on stage 3.

mlyle 5y ago
The thing is, not too much can be expected to break from a 64 bit time_t. Only stuff that directly shoves time_t's over the network or to disk -- a bad practice -- will. Note anything that builds on x86-64 or other 64 bit architectures has already figured out how to tolerate 64 bit time_t's. The major reason it's not safe to build with a 64 bit time_t is because you don't know whether other libraries are. If the C library cuts over, when people/distributions move to the new library version, they know that's not a concern. Defaults change in tooling all the time, requiring code changes for distributions bundling newer tooling/libraries. This one would require less change than most. Of course, it's possible to survive a 64 bit time_t and still not be 2038-safe. But at least you can be correct if you have a C library and other libraries that will tolerate 64 bit time_t's.
- nextaccountic 5y ago
  So the fix is to list all libraries in popular distros that break with time_t being 64 bits, file issues for all of them, and track progress somehow. Messing with the defaults is only useful if the ensuing breakage is promptly fixed.
  - mlyle 5y ago
    > So the fix is to list all libraries in popular distros that break with time_t being 64 bits All libraries in popular distros build on x86-64, which in turn means they use a 64 bit time_t there. It's time for 32 bit architectures to join 64 bit architectures in having a 64 bit time_t. Anything that ships today in distributions will ship in embedded systems for 5+ years. And then a lot of those embedded systems (too many) will last a long time. 2026 is getting pretty uncomfortably close to 2038.

3 ms·

I think it lets developers opt-in to fixing their glibc-dependent programs ahead of time, so there's less work to do on stage 3.

by MichaelBurge 5y ago

mlyle 5y ago
The thing is, not too much can be expected to break from a 64 bit time_t. Only stuff that directly shoves time_t's over the network or to disk -- a bad practice -- will. Note anything that builds on x86-64 or other 64 bit architectures has already figured out how to tolerate 64 bit time_t's. The major reason it's not safe to build with a 64 bit time_t is because you don't know whether other libraries are. If the C library cuts over, when people/distributions move to the new library version, they know that's not a concern. Defaults change in tooling all the time, requiring code changes for distributions bundling newer tooling/libraries. This one would require less change than most. Of course, it's possible to survive a 64 bit time_t and still not be 2038-safe. But at least you can be correct if you have a C library and other libraries that will tolerate 64 bit time_t's.
- nextaccountic 5y ago
  So the fix is to list all libraries in popular distros that break with time_t being 64 bits, file issues for all of them, and track progress somehow. Messing with the defaults is only useful if the ensuing breakage is promptly fixed.
  - mlyle 5y ago
    > So the fix is to list all libraries in popular distros that break with time_t being 64 bits All libraries in popular distros build on x86-64, which in turn means they use a 64 bit time_t there. It's time for 32 bit architectures to join 64 bit architectures in having a 64 bit time_t. Anything that ships today in distributions will ship in embedded systems for 5+ years. And then a lot of those embedded systems (too many) will last a long time. 2026 is getting pretty uncomfortably close to 2038.