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

[Bernd Schubert <bernd@bsbernd.com>]

On 1/5/26 13:09, Arnd Bergmann wrote:
> On Mon, Jan 5, 2026, at 09:50, Bernd Schubert wrote:
>> On 1/5/26 09:40, Thomas Weißschuh wrote:
>>> On Sat, Jan 03, 2026 at 01:44:49PM +0100, Bernd Schubert wrote:
>>>
>>>>> libfuse3.so.3.19.0.p/fuse_uring.c.o -c
>>>>> ../../../home/runner/work/libfuse/libfuse/lib/fuse_uring.c
>>>>> ../../../home/runner/work/libfuse/libfuse/lib/fuse_uring.c:197:5: error:
>>>>> format specifies type 'unsigned long' but the argument has type '__u64'
>>>>> (aka 'unsigned long long') [-Werror,-Wformat]
>>>>>   196 |                 fuse_log(FUSE_LOG_DEBUG, "    unique: %" PRIu64
>>>>> ", result=%d\n",
>>>>>       |                                                       ~~~~~~~~~
>>>>>   197 |                          out->unique, ent_in_out->payload_sz);
>>>>>       |                          ^~~~~~~~~~~
>>>>> 1 error generated.
>>>>>
>>>>>
>>>>> I can certainly work it around in libfuse by adding a cast, IMHO,
>>>>> PRIu64 is the right format.
>>>
>>> PRIu64 is indeed the right format for uint64_t. Unfortunately not necessarily
>>> for __u64. As the vast majority of the UAPI headers to use the UAPI types,
>>> adding a cast in this case is already necessary for most UAPI users.
> 
> Which target did the warning show up on? I would expect the patch
> to not have changed anything for BSD, since not defining __linux__
> makes it use the stdint types after all.
> 
> On alpha/mips/powerpc, the default is to use 'unsigned long' unless
> the __SANE_USERSPACE_TYPES__ macro is defined before linux/types.h
> gets included, and we may be able to do the same on other
> architectures as well for consistency. All the other 64-bit
> architectures (x86-64, arm64, riscv64, s390x, parisc64, sparc64)
> only provide the ll64 types from uapi but seem to use the l64
> version both in gcc's predefined types and in glibc.
> 
>>>> I think what would work is the attached version. Short interesting part
>>>>
>>>> #if defined(__KERNEL__)
>>>> #include <linux/types.h>
>>>> typedef __u8	fuse_u8;
>>>> typedef __u16	fuse_u16;
>>>> typedef __u32	fuse_u32;
>>>> typedef __u64	fuse_u64;
>>>> typedef __s8	fuse_s8;
>>>> typedef __s16	fuse_s16;
>>>> typedef __s32	fuse_s32;
>>>> typedef __s64	fuse_s64;
>>>> #else
>>>> #include <stdint.h>
>>>> typedef uint8_t		fuse_u8;
>>>> typedef uint16_t	fuse_u16;
>>>> typedef uint32_t	fuse_u32;
>>>> typedef uint64_t	fuse_u64;
>>>> typedef int8_t		fuse_s8;
>>>> typedef int16_t		fuse_s16;
>>>> typedef int32_t		fuse_s32;
>>>> typedef int64_t		fuse_s64;
>>>> #endif
>>>
>>> Unfortunately this is equivalent to the status quo.
>>> It contains a dependency on the libc header stdint.h when used from userspace.
>>>
>>> IMO the best way forward is to use the v2 patch and add a cast in fuse_uring.c.
>>
>> libfuse is easy, but libfuse is just one library that might use/copy the
>> header. If libfuse breaks the others might as well.
> 
> 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.

> 
> The #else side could perhaps be left out here.

Maybe we should keep it for safety? Less for kernel, but more for
userspace- we don't know in which environments/libs the header is used.

> 
>> Maybe you could explain your issue more detailed? I.e. how are you using
>> this include exactly?
> 
> I'm interested specifically in two aspects:
> 
> - being able to build-test all kernel headers for continuous
>   integration testing, without having to have access to libc
>   headers for each target architecture when cross compiling.
> 
> - layering kernel headers such that kernel headers never depend
>   on libc headers and (in a later stage) any kernel header
>   can be included without clashing with libc definitions. 

Thank you, I think it would good to add these details to the commit message.

Thanks,
Bernd