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: <deff86e1-f124-4e5d-9313-d7339bcc664a@bsbernd.com>
Date: Fri, 9 Jan 2026 14:46:02 +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 14:11, David Laight wrote:
> On Fri, 9 Jan 2026 11:55:30 +0100
> Thomas Weißschuh <thomas.weissschuh@...utronix.de> wrote:
> 
>> On Fri, Jan 09, 2026 at 11:45:33AM +0100, Bernd Schubert wrote:
>>>
>>>
>>> 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.  
>>
>> These changes to format strings are what we are trying to avoid.
> 
> 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.

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.

Thanks,
Bernd