From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D3072DC789 for ; Fri, 9 Jan 2026 19:13:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767986019; cv=none; b=fNZX7aY79jZVKPszJZX78awLmMgw0aMz3yV+R2nL4t8EcPop4XlLS5IVhY3agi9qhox+qi+lCSMywFGssfkSm7cebBjOjh6NGEAWj63FOEXfapObjRoCuipLDII2/ZqwN/yor/QUtK6dJpJqeVaaL4vfKDLwPt9ExdFwce3ZjGQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767986019; c=relaxed/simple; bh=mVe3a4x+Xf9izzeH1nMO6cG5fRFO7E2iLNPnBx/aYQc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=HCzObYiIRN1GSKi+N7GG2hRkOAONT6gBaokEMSnWT0ry4URD/gCvO39wIyteWZnqXpnxIX/1BEN4kT7qwEBtGn8ScMyQjglUTOMe5mUyafSMIGYRxIC8/iOZWojN+l/uAoNklxS4pPqIyjh+S4+8LrPrtUuOe9LROdW1r0lRC+M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Q6aszFdu; arc=none smtp.client-ip=209.85.160.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Q6aszFdu" Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-4eda6c385c0so33986571cf.3 for ; Fri, 09 Jan 2026 11:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767986017; x=1768590817; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=TAbGBdKfZWhiud4JJjy+Srhy+srE9kGSFCkEN7+Ee98=; b=Q6aszFduu3GpUA26YHzkV3DQBphe7ehkdo9xNhItpOZCrdTKvDn/BQa/gM33GYk9jL t+aazTp/0MT6Nlvr9E/0Jh6ojYEY7VEkuHA+HG0mUEKzzbZYL6EK1ly73Fhgt/MQ/cGF nIe460tZ4+K69+xysU5IZMfx2KmaHibVODqAoJ6EhH/RWJAhi/J50EUSWsOmR0ODON4b kujqygEYD/lzXdig6K+F5mqoUobMKmqjMhin0tJ2zOT2l1bL7C76btlg9pMwaJx97w6t u52IIf/KO/6ok1R7CFlqJDWRvGcG/Jl6OVeY9ytkZhI9kaCVqOE5lEx0bnFdFcZU7fhu +I8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767986017; x=1768590817; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TAbGBdKfZWhiud4JJjy+Srhy+srE9kGSFCkEN7+Ee98=; b=E4uqv9EEW68FsU7Zq1Gw62yU6TQS8E0fBZGZhF22yKijVkDwCcEubQGCmN0w+EXX9q y1JrjfYd0jUZFureXYhw7eiQrklT4wBPVRjbePf5Z7IeJPnZBaUkU5hUrW5XbtkxPh4x 4lGTufYDWI3yCpD5hH78YIejNzDkGrsqRql4kWyNlpVpj6/wzKybaOekq6WKhw8JsIIE B/escPf3vHGXgEwyF6qT8agATk2DcQZ3nvBQYbGbX1rap2aUEIowkSv2huo/RQY6oYl9 lL03vcAkhGQbCGNKd/4piszJRoBtJL1G6miPHzX6XVdA8usIiRbwDsWIxsTkTr7FP6lH avDg== X-Forwarded-Encrypted: i=1; AJvYcCWEi+nGFp8H0Qw/AMDrMm+aTq1mtKIKdLBXgfn98sbSUdTwKpq/iYZkiWss1PS1H6fq3Vb0CmL4rO9IN4o=@vger.kernel.org X-Gm-Message-State: AOJu0YzcxYJPR1b9BVWoUkIOOrHR/g5g+mSZ5X9vm+YO9N0TGyjGfrrg 7AgdlV233HYwAWjsZzwF+MH+zWkswvN9019r3Va5NNYK6IqUrKpHRO6h X-Gm-Gg: AY/fxX5wEwxBm734a9UiBymUpKVK0itxEtc5J82/rZNzlDn710JrrJoiYPn79Lzubkq vq/3lf4/dc4IA8roWFUdSW8mGSS+JVbj8LOwbTpEhP30VJcygJgkLSpfF/3h8M8taj/7LFhJVKH WkZ1uDTd6VTLhjjKkIzfEtWiJ3tx3Mo32h59sPzyFOynZlKkG9yxKTDV3NVRR8juwCA4LmYtluW 0iXhyGezH133aXUKjtmVHyL2NJp8KEO7KEpQZv8Y+ERWsYQdpLJjrEDAVkYcPm9ApalPRvI+g6o M/WkgCly5llNkapJrfd78vQTQml3BdSrRLIWOmkrxgRfa4gDd+59DcxVZVvcFwHhTNTDyBxmhAe EuUQD+c3ZsD2SQhYzkHhsWGLMilJZ7IZoVPQVbYZPiKpCzGU243qR2aHS/NIW2whox4Siw2eDqd 107w1qGSCtixjz7RRXTPhJU04RY/cDseVFy62E+56yT7KX6DUjI1ND X-Google-Smtp-Source: AGHT+IEiDct/J6kDHFO34j6HlpzLUhRX05gxT5R+Hps5SBUP0wHRbRg5BCKl4NIyotg1aayFyIgqtw== X-Received: by 2002:a05:622a:88:b0:4ee:7ee:df70 with SMTP id d75a77b69052e-4ffb4a6069emr144350721cf.80.1767986016870; Fri, 09 Jan 2026 11:13:36 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4ffa8d39230sm75391501cf.6.2026.01.09.11.13.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 11:13:36 -0800 (PST) Date: Fri, 9 Jan 2026 19:13:33 +0000 From: David Laight To: Bernd Schubert Cc: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= , Arnd Bergmann , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] fuse: uapi: use UAPI types Message-ID: <20260109191333.4b266966@pumpkin> In-Reply-To: References: <20251230-uapi-fuse-v2-1-5a8788d62525@linutronix.de> <8efcbf41-7c74-4baf-9d75-1512f4f3fb03@bsbernd.com> <20260105092847-f05669a4-f8a1-498d-a8b4-dc1c5a0ac1f8@linutronix.de> <51731990-37fe-4821-9feb-7ee75829d3a0@bsbernd.com> <2c1dc014-e5aa-4c1d-a301-e10f47c74c7d@app.fastmail.com> <20260109085917-e316ce57-5e78-4827-96d7-4a48a68aa752@linutronix.de> <20260109103827.1dc704f2@pumpkin> <20260109114918-1c5ea28d-f32d-49e5-affb-cc3c74c4dd5b@linutronix.de> <20260109131134.7aba4acf@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 9 Jan 2026 14:46:02 +0100 Bernd Schubert wrote: > On 1/9/26 14:11, David Laight wrote: > > On Fri, 9 Jan 2026 11:55:30 +0100 > > Thomas Wei=C3=9Fschuh wrote: > > =20 > >> On Fri, Jan 09, 2026 at 11:45:33AM +0100, Bernd Schubert wrote: =20 > >>> > >>> > >>> On 1/9/26 11:38, David Laight wrote: =20 > >>>> On Fri, 9 Jan 2026 09:11:28 +0100 > >>>> Thomas Wei=C3=9Fschuh wrote: > >>>> =20 > >>>>> On Thu, Jan 08, 2026 at 11:12:29PM +0100, Bernd Schubert wrote: = =20 > >>>>>> > >>>>>> > >>>>>> On 1/5/26 13:09, Arnd Bergmann wrote: =20 > >>>>>>> On Mon, Jan 5, 2026, at 09:50, Bernd Schubert wrote: =20 > >>>> ... =20 > >>>>>>> I don't think we'll find a solution that won't break somewhere, > >>>>>>> and using the kernel-internal types at least makes it consistent > >>>>>>> with the rest of the kernel headers. > >>>>>>> > >>>>>>> If we can rely on compiling with a modern compiler (any version of > >>>>>>> clang, or gcc-4.5+), it predefines a __UINT64_TYPE__ macro that > >>>>>>> could be used for custom typedef: > >>>>>>> > >>>>>>> #ifdef __UINT64_TYPE__ > >>>>>>> typedef __UINT64_TYPE__ fuse_u64; > >>>>>>> typedef __INT64_TYPE__ fuse_s64; > >>>>>>> typedef __UINT32_TYPE__ fuse_u32; > >>>>>>> typedef __INT32_TYPE__ fuse_s32; > >>>>>>> ... > >>>>>>> #else > >>>>>>> #include > >>>>>>> typedef uint64_t fuse_u64; > >>>>>>> typedef int64_t fuse_s64; > >>>>>>> typedef uint32_t fuse_u32; > >>>>>>> typedef int32_t fuse_s32; > >>>>>>> ... > >>>>>>> #endif =20 > >>>>>> > >>>>>> I personally like this version. =20 > >>>>> > >>>>> Ack, I'll use this. Although I am not sure why uint64_t and __UINT6= 4_TYPE__ > >>>>> should be guaranteed to be identical. =20 > >>>> > >>>> Indeed, on 64bit the 64bit types could be 'long' or 'long long'. > >>>> You've still got the problem of the correct printf format specifier. > >>>> On 32bit the 32bit types could be 'int' or 'long'. > >>>> > >>>> stdint.h 'solves' the printf issue with the (horrid) PRIu64 defines. > >>>> But I don't know how you find out what gcc's format checking uses. > >>>> So you might have to cast all the values to underlying C types in > >>>> order pass the printf format checks. > >>>> At which point you might as well have: > >>>> typedef unsigned int fuse_u32; > >>>> typedef unsigned long long fuse_u64; > >>>> _Static_assert(sizeof (fuse_u32) =3D=3D 4 && sizeof (fuse_u64) =3D= =3D 8); > >>>> And then use %x and %llx in the format strings. =20 > >> > >> These changes to format strings are what we are trying to avoid. =20 > >=20 > > Where do PRIu64 (and friends) come from if you don't include stdint.h ? > > I think Linux kernel always uses 'int' and 'long long', but other > > compilation environments might use 'long' for one of them [1]. > > So while you can define ABI correct PRIu64 and PRIu32 you can't define > > ones that pass compiler format checking without knowing the underlying > > C types. =20 >=20 > libfuse uses PRIu64 and it make heavy usage of stdint.h in general, I > don't think building it in that no-libc environment would work. But that > doesn't mean the header couldn't be included in another lib that works > differently. That means you need to 'fake up' definitions equivalent to those from stdint.h when it isn't available. I don't think checking for __UINT64_TYPE__ will work if you need printf to work - since I don't remember the compiler having anything that will help you generate a correct PRIu64. (And I wouldn't like to guarantee that stdint.h always matches the compiler internal configuration.) If stdint.h is already included PRIu64 (etc) will be defined and all is fin= e. If __KERNEL__ is defined then you can use 'long long' and 'int' (and define matching PRIu64 if needed for consistency). Otherwise you need to include stdint.h. Perhaps you could check '#if defined(__KERNEL__) || defined(__NO_STDINT_H__) then an environment that doesn't have stdint.h would still compile (with an extra -D__NO_STDINT_H__ on the command line). David >=20 > Thanks, > Bernd