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] [day] [month] [year] [list]

Message-ID: <20260109191333.4b266966@pumpkin>
Date: Fri, 9 Jan 2026 19:13:33 +0000
From: David Laight <david.laight.linux@...il.com>
To: Bernd Schubert <bernd@...ernd.com>
Cc: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 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 14:46:02 +0100
Bernd Schubert <bernd@...ernd.com> wrote:

> On 1/9/26 14:11, David Laight wrote:
> > 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.  
> 
> 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.

That means you need to 'fake up' definitions equivalent to those from
stdint.h when it isn't available.
I don't think checking for __UINT64_TYPE__ will work if you need printf
to work - since I don't remember the compiler having anything that will
help you generate a correct PRIu64.
(And I wouldn't like to guarantee that stdint.h always matches the compiler
internal configuration.)

If stdint.h is already included PRIu64 (etc) will be defined and all is fine.
If __KERNEL__ is defined then you can use 'long long' and 'int' (and define
matching PRIu64 if needed for consistency).
Otherwise you need to include stdint.h.

Perhaps you could check '#if defined(__KERNEL__) || defined(__NO_STDINT_H__)
then an environment that doesn't have stdint.h would still compile (with an
extra -D__NO_STDINT_H__ on the command line).

	David

> 
> Thanks,
> Bernd