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: <20260109114918-1c5ea28d-f32d-49e5-affb-cc3c74c4dd5b@linutronix.de>
Date: Fri, 9 Jan 2026 11:55:30 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Bernd Schubert <bernd@...ernd.com>
Cc: David Laight <david.laight.linux@...il.com>, 
	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 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.

> The test PR from Thomas succeeds in compilation and build testing. Which
> includes 32-bit cross compilation
> 
> https://github.com/libfuse/libfuse/pull/1417

Unforunately there might still be issues on configurations not tested by the CI
where the types between the compiler and libc won't match.
But if it works sufficiently for you, I'm fine with it.

Also with the proposal from Arnd there were format strings warnings when
building the kernel, so now I have this:

#if defined(__KERNEL__)
#include <linux/types.h>
typedef __u64		fuse_u64;
...

#elif defined(__UINT64_TYPE__)
typedef __UINT64_TYPE__		fuse_u64;
...

#else
#include <stdint.h>
typedef uint64_t		fuse_u64;
...
#endif  


Thomas