I think glibc is right to not change the defaults out from under the feet of users. “ This is the worst possible way to do this. Consider libraries: what if a dependency is built with -D_TIME_BITS=64, and another dependency is built without, and they need to exchange struct timespec or similar with each other? ” - this argument makes no sense to me. If you need new features and new values update your flags rather than breaking any program that depends on your CLI API
> If you need new features and new values update your flags rather than breaking any program that depends on your CLI API
The thing is, 2038 is less and less far away with each day that goes by. Especially since real programs often have to use future timevalues (and often further in the future than one would think).
Stuff has to change at some point. A glibc major version which changes the structures and typedefs for all 32 bit code could handle it.
But as it stands now, someone who wants to make a 32 bit program y2038-compliant will have a hard time doing it: they can't safely hand time values to any library that is possibly compiled differently.
This punts it to whom, distro maintainers? They have to try and rebuild everything with the correct define? And the lone end-user who does gcc -o myfile myfile.c gets code that's broken against the system libraries? Or they patch glibc itself and ship a glibc that's ABI incompatible with everyone else. Meh.
It is only changed from under their feet if it is done without communication. Most important is to communicate a plan. Tell the users that at from date X, all new releases will have the default changed.
