[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3e78f70550dfe1a9277de3b4d3373a682e2b70ec.camel@alba.sh>
Date: Tue, 18 Mar 2025 23:49:43 +0100
From: Alba Mendez <me@...a.sh>
To: musl@...ts.openwall.com
Subject: Making user libraries Y2038 compatible?
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.
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.
