From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14556 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: Mon, 12 Aug 2019 14:01:19 -0400 Message-ID: <20190812180119.GU9017@brightrain.aerifal.cx> References: <20190810175808.GA13205@brightrain.aerifal.cx> <20190811021818.GM9017@brightrain.aerifal.cx> <20190812015514.GO9017@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="159015"; 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-104325-glibc-alpha=m.gmane.org@sourceware.org Mon Aug 12 20:01:37 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 1hxEdU-000fFI-D3 for glibc-alpha@blaine.gmane.org; Mon, 12 Aug 2019 20:01:36 +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=Des6 uu/ziUHBVYziX8LoL3c7hX3SbXqm0ucYhIlSgQazXzv70Tixg5ntMzvFGonmUAit TUPPO5ue3Cz9rlcwMWCFYfqwMSFjl6lOa/URVNwEdNn7+3v/EaMmq/0EvFF0pUtu NdXCF2zfabwqfn/hLp0DSaTLyb0Y1xkF+iGzdEE= 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=2XxFuzKVRn oj6ohwOwARFCBIQZo=; b=enrX3//1HF9xeUXLq8DLbrc7X377Y1bhBrsHqttC0A eRghJZMWCVdVNpTaymZJurC44CD4NQkNpaOYmyNCc+OR2z2BS+3dXZ6k8yS/od0J khwmiOzTKgzy5H1g1NqmafuE1GIETZlx1n/PHzhTLk/+7rzwA9vs/Jir9eaz2749 s= Original-Received: (qmail 90937 invoked by alias); 12 Aug 2019 18:01:31 -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 90928 invoked by uid 89); 12 Aug 2019 18:01:31 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: brightrain.aerifal.cx Content-Disposition: inline In-Reply-To: <20190812015514.GO9017@brightrain.aerifal.cx> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:96680 gmane.linux.lib.musl.general:14556 Archived-At: On Sun, Aug 11, 2019 at 09:55:14PM -0400, Rich Felker wrote: > 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. Apologies; I was under a longstanding mistaken impression that glibc used the kernel stat64 types, and had per-arch bits headers to provide them, but apparently it doesn't and always uses its own fixed, fairly clean layout (sadly without reserved space for expansion), though. So indeed it would be a little bit of an uglification to add time64-on-32-bit-arch members here. I still think the benefits to minimizing breakage of applications (and avoiding the need for duplicate [n]ftw implementations and symbol redirects, which nobody has proposed doing yet, likely because nobody even realized they would have been needed) are worth it, but my assessment was wrong. This also means whatever glibc decides to do about struct stat is irrelevant to musl's glibc-ABI-compat goals; what I assumed was working now is in fact broken, but doesn't matter because the __xstat shims can fix it up if desired. Rich