From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14325 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Arnd Bergmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Revisiting 64-bit time_t Date: Mon, 1 Jul 2019 16:42:29 +0200 Message-ID: References: <20190628150659.GD1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="178052"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14341-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 16:43:01 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hhxWG-000kDZ-HE for gllmg-musl@m.gmane.org; Mon, 01 Jul 2019 16:43:00 +0200 Original-Received: (qmail 10230 invoked by uid 550); 1 Jul 2019 14:42:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 10212 invoked from network); 1 Jul 2019 14:42:58 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6Za8DrYinu8dinTnZ5unDBmfa09u5tZ0qE1s+EU99Bc=; b=BOf64plj99PWLHhrmhS4gkNdfNb28x2D/kfGG7HjFeI18NwfJdn/fvdFsoeP5Lod4u hLeyD6oOqGHU8aH6pOmbxvFf+QEV03j2KfUNmKs9P6DU7aUk9lkHoa5qNBfuxcLSX7JD jMHWQOyxQ80iq1ccw0CrQEYytxPkToLbVZFse4Txeb8xvkKAMV0BVOBB31wjO3uIm4YZ C2hKCT0D38VK5s81xIWWBufvHjF6tEtsZrrMVVHOCyZy9Xa+crUdEUUL6EJIwInuvuig zQ+m5kG0iWaco8uDDJ3nLTZBoj6Nrs7F98qQqUdA3BNcQQJ3QGbxF0m8cIxMHhhHSW6S HeuQ== X-Gm-Message-State: APjAAAUSjEag7J7924clRfcjpkG4iwCpvc0FrtibUhYYjOkNy1iaeeoh x6t4/MXERZ3OqB5rd/TjdaG0neYP7G2fVYxzhFaN3Ja1 X-Google-Smtp-Source: APXvYqzfL75JVsOy4x/ec3UHU6xQp9Rcb6XEyGMBgTpIjEFfEaiNtBE7IWlI3sk4nZYjVdd1m8ocOTT5oV/+Dnsc1vM= X-Received: by 2002:ac8:3485:: with SMTP id w5mr20061321qtb.142.1561992165942; Mon, 01 Jul 2019 07:42:45 -0700 (PDT) In-Reply-To: <20190628150659.GD1506@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14325 Archived-At: On Fri, Jun 28, 2019 at 5:07 PM Rich Felker 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