From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14548 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general Subject: Re: [musl] Re: time64 abi choices for glibc and musl Date: Sun, 11 Aug 2019 21:55:14 -0400 Message-ID: <20190812015514.GO9017@brightrain.aerifal.cx> References: <20190810175808.GA13205@brightrain.aerifal.cx> <20190811021818.GM9017@brightrain.aerifal.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="230316"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: libc-alpha@sourceware.org, musl@lists.openwall.com To: Paul Eggert Original-X-From: libc-alpha-return-104305-glibc-alpha=m.gmane.org@sourceware.org Mon Aug 12 03:55:26 2019 Return-path: Envelope-to: glibc-alpha@blaine.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hwzYU-000xlZ-5R for glibc-alpha@blaine.gmane.org; Mon, 12 Aug 2019 03:55:26 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=Ia4D bcSZQjv4S6j7r30shoJMMSYMcWJa/O8OpyyyMqUaOTr/U4nARNgTfL+BbUCBYHN9 0SaH3o282Gi2mFQxF2ajOLYTPQHXEOrwK55+1/UDm86hSGuoYQEO4lWXkwHugezk +trS8tFe79R16hjW8NOzkhXbZG00Jb1X+z0WpFM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=jyDcrDWO2n 5U+d/rDJSMF0c0O8U=; b=dw4N4uzwoJM3zzFEABN6/os4mj4NopXqN28NavlJDF mxYKDMHmhxMy+pi4SKzdQJGJI059aOUUmyQ7j+nrbebrFiNneRrexJNhcYRlytjU PsD0D+1caPAfNlpFZ8rj6zNF2n3u0xly2kDwG8K7WPH+f1hVBu7C2Rys6MwsIUTN Y= Original-Received: (qmail 81251 invoked by alias); 12 Aug 2019 01:55:20 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 80680 invoked by uid 89); 12 Aug 2019 01:55:20 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: brightrain.aerifal.cx Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.comp.lib.glibc.alpha:96660 gmane.linux.lib.musl.general:14548 Archived-At: On Sun, Aug 11, 2019 at 05:31:48PM -0700, Paul Eggert wrote: > Rich Felker wrote: > >this is a best-effort > >thing anyway, and can't inherently be expected to work, but the choice > >that makes things easy on the libc implementation side is *also* the > >choice that makes this work best. > > It doesn't entirely simplify libc, as it enlarges struct stat and > (more importantly) makes struct stat tricky. This is a judgment > call, but I would say we're better off in the long run with a > simpler struct stat that ordinary programmers will understand > easily, even if this complicates nftw implementation during the > transition. The various archs already have random junk padding in struct stat. It's true that the time64 transition would allow the 32-bit archs to do away with this and invent a uniform definition that they can all share, but the 64-bit archs would still be stuck with all the legacy stuff, and struct stat still needs to be an arch-specific bits header anyway. I don't see much value in making things "prettier" for 32-bit here when we can't do the same for 64-bit, especially when the vast majority of users are 64-bit. The reason I mention "random junk padding" is that, in the long term, that's what the time32 members end up becoming. If building with _TIME_BITS=32 is no longer supported at some point, they don't even have to be called __st_atim32 or whatever anymore; they can be called __reservedN or whatever, and effectively they're just like the other padding junk in struct stat. If at some point in the distant, distant future time32 binaries are no longer supported at all, these reserved members could even be repurposed for something else if needed. Aside from time_t and struct timespec themselves, which *have to* change in an incompatible way, struct stat is probably the most widely used time_t-dependent data type defined by libc. As stated before, making things work when time32 and time64 code get linked in the same program is inherently a best-effort thing at best, but struct stat is one case where making a best effort will usually be sufficient not to have any breakage (and only non-serious, invalid-read breakage if breakage happens). Both glibc and musl place significant value on stable ABI and compatibility with users' binaries and libraries. For glibc, every gratuitous breakage when time32 and time64 code gets mixed is going to make users hesitant to define _TIME_BITS=64, and thereby delay the eventual switchover of the default. The switchover very well might get delayed well past "too late" already, leaving broken stuff all over the place with 2038 quickly approaching. For musl, there is not going to be a build option unless you roll your own by building with old headers. After the time64 release, all newly built programs will be using time64. As such, distros are going to have to deal with any breakage that occurs right away, and users who've built stuff themselves are going to end up dealing with mismatches. As part of being responsible about our promises of stable ABI, I do not want to be introducing gratuitous breakage where it could easily have been avoided. The other types mentioned in my original email are fairly inconsequential (not going to appear in interfaces between libraries), but stat is important and does appear. For what it's worth, as long as glibc is doing the __xstat thing, we can provide ABI-compat shims through that and not really care if the layout matches. But I really think glibc would be better off not breaking things here, so that the transition is as painless as possible. Rich