From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14546 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: Sat, 10 Aug 2019 22:18:18 -0400 Message-ID: <20190811021818.GM9017@brightrain.aerifal.cx> References: <20190810175808.GA13205@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="108368"; 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-104300-glibc-alpha=m.gmane.org@sourceware.org Sun Aug 11 04:18:39 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 1hwdRO-000S3u-J3 for glibc-alpha@blaine.gmane.org; Sun, 11 Aug 2019 04:18:39 +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=jXcP F42EQxsZej7eooRk3KUQL4udot/AG32ZpoFABOTS7FU2t1CmVQ4u6cTJaC0jR/H6 ZKBBVejd49GsQ6jrny6BXrrewZ+Y0JfIFBfMn8vZLNYLMq3/FCUkVIAMjJ8XJFoV iw/vs6P8DkRIvkQj3TscErsXPxnupuW59DsZ6rs= 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=FgE93a8ZKS 7YH82qbz/zryAsaYU=; b=fTZQ9rH/9cQClr/GKkoX1JjyrC+H3jI2fY9PeP0gfP AzmChqAVboU6TD33Pw/SmpWY0xkgV/X1vX1Acy6l5jzXAm5U0Gn5qVqHPmBGyF+W X5uxxwwE7qgC/n81Z0HbNH+OSsXvdvvYEocRSST6uYbA5AwyOqxqDXWvrt25ga3H k= Original-Received: (qmail 86277 invoked by alias); 11 Aug 2019 02:18:32 -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 86269 invoked by uid 89); 11 Aug 2019 02:18:32 -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:96655 gmane.linux.lib.musl.general:14546 Archived-At: On Sat, Aug 10, 2019 at 01:15:34PM -0700, Paul Eggert wrote: > Rich Felker wrote: > >For struct stat, I think it's almost necessary to preserve the > >existing layout and add new time64 members on the end, and to continue > >filling in the time32 members. > > This won't be reliable for applications that call 'stat', fiddle > with the timestamps in the resulting 'struct stat', and then pass > the fiddled-with struct to some other function. If they fiddle with > the 64-bit timestamp the 32-bit copy will become wrong, and vice > versa. > > There are similar issues for applications that create struct stat > values by hand, without calling a 'stat'-like function. Changing any of the types defined by libc obviously alters the ABI between any two consumers of these types that uses the changed types as part of the interface between them. The only thing we can *guarantee* works is the interface between libc and a single consumer of libc. Since there's no function in libc which reads from a stat structure provided by the application, your concern seems to apply only to the case that's inherently a best-effort thing. Still, here it is useful to make a best effort, since the only typical way stat structures are passed around is share (unmodified) results obtained by performing one of the stat functions on a file. The [n]ftw matter, by itself, is something entirely different, and pertains to use of libc by a single consumer. Internally, [n]ftw performs stat on files and passes the result to a callback provided by the application. If the stat structure is not such that it can be accepted by either time32 or time64 callers, then [n]ftw need to be redirected symbols and there need to be two copies of the implementation, one that calls the old time32 stat and one that calls the time64 stat. This is a gratuitous pain on the implementation side. Now the two are actually related in some sense, because this same idiom, of passing stat results back to a caller, is fairly common in library code outside libc that does directory listings, tree walks, etc. The same condition that makes it [n]ftw painless on the libc implementation side also makes it so that this kind of library works with time32 callers when the library was built for time64 (assuming there are no other points of breakage). Again, 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. Thereby I consider it the most reasonable choice. Rich