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=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 f0ad5d4d for ; Mon, 17 Feb 2020 09:11:01 +0000 (UTC) Received: (qmail 19757 invoked by uid 550); 17 Feb 2020 09:11:00 -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 19739 invoked from network); 17 Feb 2020 09:10:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581930648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zlVKC72zSmpTCKhfu++nO29Hc24V7ufWArihHEQA+sY=; b=e6bu4Juv3QRfhn1B8Abe5Eyr7ZKB4nF6bwBEikyAAZgEtbmr7J8ZYvJpCEpHkUp3vp5VDt rfjupKc5gRPSs6byZ2j6cSD7tlrjkqyM8HZP+rkniquOakxTKUtDGwlcwfi8YEZ7z4iP+l jMCeIt1d9jyohztqNPR9Bz/FIYw9WT4= From: Florian Weimer To: Rich Felker Cc: musl@lists.openwall.com 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> Date: Mon, 17 Feb 2020 10:10:40 +0100 In-Reply-To: <20200128131844.GD30412@brightrain.aerifal.cx> (Rich Felker's message of "Tue, 28 Jan 2020 08:18:45 -0500") Message-ID: <87k14lwpdb.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: x-KybWEfMuq2UnEt-HNiPA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH] add statx * 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 =3D=3D 64-bit is ba= d > 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. > Arguably you could get into having something like k_[u]intNN_t or > similar, and use these, but I feel like that's just gratuitous > ugliness. The userspace type for 64-bit fixed-size fields is > [u]int64_t and we should be promoting its consistent usage, not > fragmenting things around kernel uapi mistakes. I'm not convinced it's a mistake. > (Perhaps kernel uapi headers should be fixed so that, when __KERNEL__ > is not defined, they include and define __u64 etc. in terms > of the stdint types?) This breaks the existing format specifiers. The kernel choices have been deliberately made in such a way that you can use %llu for printing __u64 values. Thanks, Florian