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: <20260109131134.7aba4acf@pumpkin>
Date: Fri, 9 Jan 2026 13:11:34 +0000
From: David Laight <david.laight.linux@...il.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Bernd Schubert <bernd@...ernd.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, 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.

[1] I can't remember where, but it might have been NetBSD where different
architectures managed to have different definitions!

	David

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