From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 4957f75c for ; Mon, 17 Feb 2020 15:29:24 +0000 (UTC) Received: (qmail 22054 invoked by uid 550); 17 Feb 2020 15:29:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 22036 invoked from network); 17 Feb 2020 15:29:22 -0000 Date: Mon, 17 Feb 2020 10:29:09 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200217152909.GW1663@brightrain.aerifal.cx> References: <20200119121247.37310-1-info@bnoordhuis.nl> <20200124140027.GT30412@brightrain.aerifal.cx> <878slw3mdo.fsf@oldenburg2.str.redhat.com> <20200124155458.GW30412@brightrain.aerifal.cx> <87k15g25q4.fsf@oldenburg2.str.redhat.com> <20200124162910.GX30412@brightrain.aerifal.cx> <87blqneuci.fsf@oldenburg2.str.redhat.com> <20200128131844.GD30412@brightrain.aerifal.cx> <87k14lwpdb.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k14lwpdb.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] [PATCH] add statx On Mon, Feb 17, 2020 at 10:10:40AM +0100, Florian Weimer wrote: > * Rich Felker: > > >> That's why the kernel always uses unsigned long long for __u64, which > >> seems a reasonable trade-off to me. It will make porting to 128-bit > >> architectures difficult. But I think we should focus on the > >> architectures we have today. > > > > I disagree strongly with the last sentence. Designing an *API* in a > > way that's not compatible with anything but long long == 64-bit is bad > > API design. > > We don't know what LL128 architectures will look like. For all we know, > they might have more expressive type descriptors for variadic functions, > so the whole issue of matching integer types with precise format > specifiers becomes moot. I don't follow. Mechanically the wrong format for long long vs int64_t *already works*; the problem at hand is that per the language, it's undefined, and rightly produces warnings. None of that would go away if LL128 archs used a fancy variadic call mechanism. Rich