[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a30RUqXJ=zDjUvHhaGpRq-na-cNv-8fkKjSKmtcHh46Uw@mail.gmail.com>
Date: Mon, 1 Jul 2019 16:42:29 +0200
From: Arnd Bergmann <arnd@...db.de>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 64-bit time_t
On Fri, Jun 28, 2019 at 5:07 PM Rich Felker <dalias@...c.org> wrote:
>
> The idea has been that users (like embedded) who don't care
> much/at-all about an ecosystem of ABI-compatible binaries, but build
> everything from source with buildroot or yocto or whatever, would
> switch right away so that their devices don't become Y2038 time bombs,
> and desktop/server distros that receive constant updates could make
> the transition at their leisure.
Distros would probably need a varying amount of time to transition,
right? Would you plan to support both time32 and time64 for a
transition period, or would a distro that is not yet confident in rebuilding
everything with time64 be stuck on the last time32 musl release
before they do?
I suppose the header files could be changed in a musl-1.2 release
if the times line up, while musl-1.1.x can still get bugfixes?
> So I'm thinking more and more about doing a different fix. In a way
> it's like how glibc did 64-bit off_t, and how they're doing 64-bit
> time_t, except it wouldn't be switchable and wouldn't default to the
> old behavior; once we pull the lever, everything would be built with
> 64-bit time_t. This would work via symbol redirction in the headers
> for the affected functions (probably via a bits header for the 32-bit
> archs), which is valid because, by virtue of using time_t or a derived
> type, the standard requires that you include the headers to get the
> declaration rather than declaring the function yourself.
Sound great to me. I don't think it would be hard to make it
conditional on top of that (just have an #ifdef __USE_TIME_BITS64
around each symbol redirect in the headers), but I also prefer the idea
that this is not something an individual compilation unit gets
to decide.
> Aside from community feedback, what's needed to make this possible, if
> it's going to happen, is some good analysis of the scope of breakage.
> Such analysis would also benefit glibc -- it would help determine how
> safe their _TIME_BITS=64 option will be and whether it can be turned
> on safely by default in the presence of old libraries built without
> it. I've already discussed this casually with a few people and it
> looks like the right starting point would be getting a Debian system
> (Debian because their repo is utterly huge) with ALL library packages
> installed and grepping /usr/include for all headers that involve
> time_t or any of the derived types. Then, manual analysis would need
> to be done to determine whether the usage actually has an impact.
Yes, this is also one of the things we eventually plan to do in Linaro,
but have not actually started.
> If there are a significant number of affected libraries and we want to
> go forward with something like this anyway, there should probably be
> an optional patch distros can use to make ldso refuse to load certain
> tagged .so files into a process where any of the 64-bit time symbols
> have been referenced. This would ensure transitioning users get an
> error message rather than silent misexecution.
For those distros that build everything from source and generally
don't update packages independently, another idea would
be to have a way to leave out all the time32 symbols. This would
immediately guarantee that they are not mixed.
Arnd
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.
