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

["Arnd Bergmann" <arnd@arndb.de>]

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

The #else side could perhaps be left out here.

> 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. 

      Arnd