Re: [PATCH v2] fuse: uapi: use UAPI types

[Bernd Schubert <bernd@bsbernd.com>]

On 1/9/26 14:11, David Laight wrote:
> On Fri, 9 Jan 2026 11:55:30 +0100
> Thomas Weißschuh <thomas.weissschuh@linutronix.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@linutronix.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