[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMKF1spsK+6CrfxNuKtR2r+-pe4VcgfOJvYJ_MiEbSeZNu+Vmg@mail.gmail.com>
Date: Tue, 18 Mar 2025 19:18:04 -0700
From: Khem Raj <raj.khem@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Making user libraries Y2038 compatible?
On Tue, Mar 18, 2025 at 4:55 PM Alba Mendez <me@...a.sh> wrote:
>
> Hi,
>
> First of all, sorry if I'm asking in the wrong list or if this has been
> asked already! User libraries understandably want to stay ABI and API
> compatible with the Y2038 proofness and LFS design, just like libc
> does, meaning:
>
> - on systems where time_t (and other types) are 32-bit by default,
> offer an additional "<name>64" symbol in addition to "<name>".
> - also on these systems, "#define <name>64 <name>" in the header if
> _TIME_BITS (or the relevant app-defined macro for the type) is 64.
>
> This allows the library to begin providing 64-bit interfaces without
> breaking ABI, and allows it to link with a user application without
> forcing the application to use the same feature test macros as the
> library.
Musl always had 64bit time_t and off_t regardless of 32bit or 64bit systems
so I guess we are good here.
>
> To do this, I think libraries need at a minimum:
>
> - a C type that refers to the original default for that platform (i.e.
> if no app-defined macros were present). glibc offers __ prefixed
> types for this purpose (__time_t, __off_t, __ino_t...)
> - a preprocessor define to check if the a platform has a 32-bit default
> (glibc offers __TIMESIZE for this purpose; this decides the size of
> all affected types, time or size related)
>
> In the absence of these mechanisms libraries resort to implementation-
> specific and often incorrect[1] heuristics, like testing for
> __BITS_PER_LONG==32 to see if the <name>64 symbol is needed (which is
> incorrect in modern 32-bit platforms that were defined after Y2038
> support was in place, like x32 or RV32).
>
> Does musl provide, or would consider providing, such a mechanism? Or am
> I approaching this from the wrong angle and libraries shouldn't be
> doing this in the first place?
>
> Many thanks,
> Alba
>
> [1]:
> https://github.com/SELinuxProject/selinux/commit/9395cc03226a0e1a220a37d71d1a4158635c4284
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
