Paul Eggert <egg...@cs.ucla.edu> writes: > One possible improvement would be to append "t32" if you want 32-bit time_t, > instead of appending "t64" for 64-bit time_t. That way, people wouldn't be > stuck with appending that confusing "t64" for the foreseeable future, and only > specialists concerned with 32-bit time_t would need to know about the issue.
But that'd change semantics in non-obvious ways. The intention behind this suggestion is to have a mechanism to communicate to packages and the toolchain alike that "yes, this system is Y2038-proof". There is currently no mechanism to do that. There isn't even a mechanism to guess based on your dependencies whether you should also enable LFS and T64 (and there can't be a general one - you'd need to detect what libraries are doing what if they have time_t or other system integers on ABI boundaries, which is not generally possible). Not that the latter would suffice - even if we changed all packages we can to use such a mechanism, there would be plenty of packages that don't (think of all the hand-rolled makefiles..). An alternative that I pondered was to teach the linker about some notion of "compatibility strings" that it would compare and reject if different, plus teaching the compiler how to emit those, plus teaching glibc to tell the compiler to emit those.. We could have key-value pairs in some section. For each key K, we could have the linker check that, for each (shared or otherwise) object either does not contain K or contains K with the same value as all the other ones, and produce an error otherwise. On the resulting object, the KV pairs would be the union of all KV pairs of all constituent objects. ... but this is for i?86, a CPU family I haven't used in ~15 years (and I suspect many also have not..), and there are other things eating my time. And it'd still require a world rebuild. > Personally, I hope backward-compatibility concerns don't require this sort of > thing. I'd rather just switch, as Debian has. The "status quo" of some packages enabling it of their own volition, and some not, leads to various subtle breakages (example: https://bugs.gentoo.org/828001). I think switching like that would not be much different. I do not know what approach Debian took, but if it is one of altering the toolchain, then this is a sure way to introduce subtle divergences between distros (this is why I've suggested we CC the GCC and binutils MLs); if it is one of teaching debhelper (is that the right tool? not sure) about it, then this will break user-compiled packages (so, ./configure && make && make install, or moral equivalent). If it is to alter libc, then, can we do libc.so.7? ;) The only actually solid approach I see today is to /somehow/ communicate to the system to not use 32-bit time, ever (and consequently, to enable LFS). I think that the "least effort" path to do that is through the tuple. There's precedent for this also, AFAIK, in the 32-bit ARM world (gnueabi/gnueabihf, whatever that means). config.guess would need to be altered a little bit. My preference is for [[ $os = *-*-gnu*t64* ]] informing glibc to completely ignore _FILE_OFFSET_BITS, _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE, and _TIME_BITS and just presume 64 for all of those system integers. This means that config.guess could undef those (in case a toolchain sets those) and include some libc file, then check for sizeof (time_t), or just have glibc define something if on a gnut64 target. > I felt the same way about the 64-bit off_t back in the 1990s. It was obvious > to > me even at the time that we would have been significantly better off making > off_t 64-bit, while keeping 32-bit off_t in the ABI for backward > compatibility; > this is what NetBSD did with time_t in 2012. Although I realize others felt > differently, I never fully understood their concerns. That is history now I fear; I also wish that time_t was made 64-bit a long ago ;) > And here I am, three decades later, still having to make changes[1] to > Autoconf's AC_SYS_LARGEFILE macro to continue to support that 30-year-old > off_t3 > mistake, and now with 64-bit time_t interacting with 64-off_t in > non-orthogonal > ways. Indeed, and the "best" part is that, whatever you do in autoconf, unless a program exists in isolation only interfacing with libc, it will break some consumer (or will be broken by some dependency) because there's no mechanism to signal the time_t size across ABI boundaries. -- Arsen Arsenović
signature.asc
Description: PGP signature
