Am Donnerstag, 5. September 2024, 20:20:32 CEST schrieb Paul Eggert: > On 2024-09-05 10:03, Andreas K. Huettel wrote: > > at least time64 implies largefile, so that will get sorted as side > > effect. > > Right, but this means the "t" in "t64" is somewhat misleading, as it's > not just about time: it also affects off_t, ino_t, etc., effects that > are in some cases more important than the time_t effects. It may well be > a good idea to use a different suffix, to remind non-experts about these > other issues. How about "wsi" for "wider system integers"? E.g., > i686-pc-linux-gnuwsi.
... or -gnutf64 (for time and files)? No objections against such variations in principle, just we should keep it as simple and straightforward as possible then. > Is the plan to call these APIs XXXt64 or XXXwsi forever, even after the > year 2038? For example, will i686-pc-linux-gnu be withdrawn in a few years? I'd expect that all the 32bit linux variants will slowly sink into obscurity. (By 2038, we're probably more concerned with the 64bit to 128bit transition.) Apart from that, I see no real need for further change later on. > How would you deal with the problem that i686-pc-linux-gnu would mean > one thing in Gentoo and something else in Debian? (This was what I was > hinting at when I suggested adding a suffix for 32-bit time_t instead of > for 64-bit.) Well, of course I would hope that I can still convince them that tacking on t64 makes sense. After all, it's easy for them now. ;) Otherwise... Following the logic of riscv versus riscv64 versus riscv32, one could come up with a "global" definition of * t64 suffix = 64bit time and lfs * no suffix = can be either, your fault for not being informative, distro default * t32 suffix = 32bit time (and ...?) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge
signature.asc
Description: This is a digitally signed message part.
