From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14547 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: [musl] Re: time64 abi choices for glibc and musl Date: Sun, 11 Aug 2019 17:31:48 -0700 Message-ID: References: <20190810175808.GA13205@brightrain.aerifal.cx> <20190811021818.GM9017@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="180655"; 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: libc-alpha@sourceware.org, musl@lists.openwall.com To: Rich Felker Original-X-From: libc-alpha-return-104304-glibc-alpha=m.gmane.org@sourceware.org Mon Aug 12 02:31:59 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 1hwyFh-000kmb-Hz for glibc-alpha@blaine.gmane.org; Mon, 12 Aug 2019 02:31:57 +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=IrzMR5k3T7Uag7i2 n02ZOPh+XQPuA10oh9MkcDWBOVt7BvMlYbDsjPIFlho74g74cuoCBspNtAqGK1Vb t3a/bQMW5o2SSSNf+Y5RUn3UAU0uY8iIPjYFMD2xohqpKTef8GKIxEq4w1duClaf ceN8FyNac5aRYDjSqjoko3IVvQI= 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=xAMVYT0GO7IOzr1lXMskSs GISck=; b=Re+pJQNfYKbQrU7SJ/SmNysSSgqiszelVVPo7ADQdr3IUSALgc1/v/ zhjqDwZ3PC0nNrQ/yKqUugphmwIChBOp7JjDlA96odh8+RPko0se5ig83h5sDY/j iTffJ101ifLpIcu3aJpX3WasNEunXegRxX3kc0j7RM6lT2SsBMPOg= Original-Received: (qmail 103810 invoked by alias); 12 Aug 2019 00:31:52 -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 103799 invoked by uid 89); 12 Aug 2019 00:31:52 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: zimbra.cs.ucla.edu In-Reply-To: <20190811021818.GM9017@brightrain.aerifal.cx> Xref: news.gmane.org gmane.comp.lib.glibc.alpha:96659 gmane.linux.lib.musl.general:14547 Archived-At: 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.