From: "Andreas K. Huettel" <dilfridge@gentoo.org>
To: Wookey <wookey@wookware.org>, Khem Raj <raj.khem@gmail.com>,
Paul Eggert <eggert@cs.ucla.edu>
Cc: libc-alpha@sourceware.org, binutils@sourceware.org,
gcc@gcc.gnu.org, config-patches@gnu.org,
distributions@lists.linux.dev, devel@lists.fedoraproject.org,
glaubitz@debian.org, maskray@google.com,
dickey@invisible-island.net, toolchain@gentoo.org
Subject: Re: Proposed CHOST change for the 64bit time_t transition
Date: Thu, 05 Sep 2024 23:54:22 +0200 [thread overview]
Message-ID: <2398337.iZASKD2KPV@noumea> (raw)
In-Reply-To: <edbc4f0b-69bc-4c93-a46a-0e3cf2d82b3e@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]
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
dilfridge@gentoo.org
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-09-05 21:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 15:48 Proposed CHOST change for the 64bit time_t transition Andreas K. Huettel
2024-09-05 0:32 ` Oskari Pirhonen
2024-09-05 2:06 ` Wookey
2024-09-05 3:10 ` Khem Raj
2024-09-05 13:50 ` Andreas K. Huettel
2024-09-05 15:39 ` Paul Eggert
2024-09-05 16:33 ` Todd Vierling
2024-09-05 16:59 ` Andreas K. Huettel
2024-09-05 17:03 ` Andreas K. Huettel
2024-09-05 18:20 ` Paul Eggert
2024-09-05 21:54 ` Andreas K. Huettel [this message]
2024-09-06 16:06 ` Arsen Arsenović
2024-09-07 0:24 ` Bruno Haible
2024-09-07 11:52 ` Arsen Arsenović
2024-09-07 0:16 ` Bruno Haible
2024-09-08 14:08 ` Arsen Arsenović
2024-09-08 23:42 ` Jacob Bachmeyer
2024-09-09 23:08 ` Arsen Arsenović
2024-09-10 10:16 ` Andreas K. Huettel
2024-09-10 14:11 ` Todd Vierling
2024-09-10 16:23 ` Florian Weimer
2024-09-05 16:39 ` Khem Raj
2024-09-05 13:49 ` Andreas K. Huettel
2024-09-07 12:32 ` Michał Górny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2398337.iZASKD2KPV@noumea \
--to=dilfridge@gentoo.org \
--cc=binutils@sourceware.org \
--cc=config-patches@gnu.org \
--cc=devel@lists.fedoraproject.org \
--cc=dickey@invisible-island.net \
--cc=distributions@lists.linux.dev \
--cc=eggert@cs.ucla.edu \
--cc=gcc@gcc.gnu.org \
--cc=glaubitz@debian.org \
--cc=libc-alpha@sourceware.org \
--cc=maskray@google.com \
--cc=raj.khem@gmail.com \
--cc=toolchain@gentoo.org \
--cc=wookey@wookware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.