linux-kernel - Re: [PATCH v2] fuse: uapi: use UAPI types

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ccdbf9b8-68d1-4af6-9ed4-f2259d1cecb4@bsbernd.com>
Date: Fri, 9 Jan 2026 11:45:33 +0100
From: Bernd Schubert <bernd@...ernd.com>
To: David Laight <david.laight.linux@...il.com>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Arnd Bergmann <arnd@...db.de>, Miklos Szeredi <miklos@...redi.hu>,
 linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] fuse: uapi: use UAPI types



On 1/9/26 11:38, David Laight wrote:
> On Fri, 9 Jan 2026 09:11:28 +0100
> Thomas Weißschuh <thomas.weissschuh@...utronix.de> wrote:
> 
>> On Thu, Jan 08, 2026 at 11:12:29PM +0100, Bernd Schubert wrote:
>>>
>>>
>>> On 1/5/26 13:09, Arnd Bergmann wrote:  
>>>> On Mon, Jan 5, 2026, at 09:50, Bernd Schubert wrote:  
> ...
>>>> 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 <stdint.h>
>>>> typedef uint64_t		fuse_u64;
>>>> typedef int64_t			fuse_s64;
>>>> typedef uint32_t		fuse_u32;
>>>> typedef int32_t			fuse_s32;
>>>> ...
>>>> #endif  
>>>
>>> I personally like this version.  
>>
>> Ack, I'll use this. Although I am not sure why uint64_t and __UINT64_TYPE__
>> should be guaranteed to be identical.
> 
> 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) == 4 && sizeof (fuse_u64) == 8);
> And then use %x and %llx in the format strings.


The test PR from Thomas succeeds in compilation and build testing. Which
includes 32-bit cross compilation

https://github.com/libfuse/libfuse/pull/1417

Checkpatch complains a bit, but I would ignore that - I had mostly only
added checkpatch to ensure people are submitting with the right
formatting (lots of commits with spaces, but the project follows kernel
style).


Thanks,
Bernd1