From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14544 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.lib.musl.general Subject: Re: time64 abi choices for glibc and musl Date: Sat, 10 Aug 2019 13:15:34 -0700 Message-ID: References: <20190810175808.GA13205@brightrain.aerifal.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="52278"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 Cc: musl@lists.openwall.com To: Rich Felker , libc-alpha@sourceware.org Original-X-From: libc-alpha-return-104299-glibc-alpha=m.gmane.org@sourceware.org Sat Aug 10 22:15:46 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 1hwXmC-000DOx-5p for glibc-alpha@blaine.gmane.org; Sat, 10 Aug 2019 22:15:44 +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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=gvc6LCkoj7qRhFDN wM1+wAF4RFHEsMV4i9cOBs+NifDYolHKRYpTYqeE5R7cpHtH4jqWnp/QoBGsCEeF rOJaaYPd/+WUCb/dnhTtORlb4T67/hdXW+46+TwwCGJ5RJZnhRu48Ti5Ps/w3m3r fWuJYXD4ge4bLrkJVxdE+2UEyY4= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=f2xJDAM8lPg6fQheA1ZvZF NNLmk=; b=s0TheCykD7b82cT/uWxUwCu2Dhy1h3lHnJvt++tNaWsePofcvodL83 9PNyCiAI8Aq/me/fLU5SlQz+AhouIfueyyZ2FbEaU36wkNUIB2a9c+zZVjXbWcoV 3BOmwDAtHf4XDAFvcBnTjLXHugRxX5T27TYn9FsdodGNpzqYafeL0= Original-Received: (qmail 67517 invoked by alias); 10 Aug 2019 20:15:39 -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 67507 invoked by uid 89); 10 Aug 2019 20:15:38 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: zimbra.cs.ucla.edu In-Reply-To: <20190810175808.GA13205@brightrain.aerifal.cx> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:96654 gmane.linux.lib.musl.general:14544 Archived-At: 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.