3 ms·
Not if you at compile time redirect calls to e.g. time() to __time64()[1]. The musl libc does something similar[2], as do the Large File Support extensions for
by irdc 4y ago
Not if you at compile time redirect calls to e.g. time() to __time64()[1]. The musl libc does something similar[2], as do the Large File Support extensions for 64-bit filesizes[3].
1. https://sourceware.org/glibc/wiki/Y2038ProofnessDesign https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
2. https://musl.libc.org/time64.html https://musl.libc.org/time64.html
3. https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fFILE_005fOFFSET_005fBITS https://www.gnu.org/software/libc/manual/html_node/Feature-T...
- kevincox 4y agoThe point is that as soon as a library stores a time_t in an ABI-relevant structure it breaks a lot of stuff. So yes, for an application only linked to glibc it works fine. But when you have different libraries liked with different versions it quickly falls apart. For example see https://lwn.net/Articles/605607/ https://lwn.net/Articles/605607/
- irdc 4y agoIndeed. And in cases like those, the application and any libraries it uses have to either agree on which time_t size to use, or perform the same rewriting as libc does. Getting libc on board is merely the first step. The same goes for _FILE_OFFSET_BITS for obvious reasons (though embedding an off_t is probably somewhat less common). Nobody said this would be easy. OpenBSD's "ABIs are for breaking"-approach resulted in them fixing this very problem almost 10 years ago: https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2 https://marc.info/?l=openbsd-cvs&m=137637321205010&w=2.