Using libc types and headers from the UAPI headers is problematic as it
introduces a dependency on a full C toolchain.

Use the fixed-width integer types provided by the UAPI headers instead.
To keep compatibility with non-Linux platforms, add a stdint.h fallback.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Changes in v2:
- Fix structure member alignments
- Keep compatibility with non-Linux platforms
- Link to v1: https://lore.kernel.org/r/20251222-uapi-fuse-v1-1-85a61b87baa0@linutronix.de
---
 include/uapi/linux/fuse.h | 626 +++++++++++++++++++++++-----------------------
 1 file changed, 319 insertions(+), 307 deletions(-)

diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
index c13e1f9a2f12..121a1552e4cd 100644
--- a/include/uapi/linux/fuse.h
+++ b/include/uapi/linux/fuse.h
@@ -245,10 +245,22 @@
 #ifndef _LINUX_FUSE_H
 #define _LINUX_FUSE_H
 
-#ifdef __KERNEL__
+#if defined(__KERNEL__)
+#include <linux/types.h>
+#elif defined(__linux__)
 #include <linux/types.h>
 #else
 #include <stdint.h>
+
+typedef	uint8_t		__u8;
+typedef	uint16_t	__u16;
+typedef	uint32_t	__u32;
+typedef	uint64_t	__u64;
+
+typedef	int8_t		__s8;
+typedef	int16_t		__s16;
+typedef	int32_t		__s32;
+typedef	int64_t		__s64;
 #endif
 
 /*
@@ -284,22 +296,22 @@
    userspace works under 64bit kernels */
 
 struct fuse_attr {
-	uint64_t	ino;
-	uint64_t	size;
-	uint64_t	blocks;
-	uint64_t	atime;
-	uint64_t	mtime;
-	uint64_t	ctime;
-	uint32_t	atimensec;
-	uint32_t	mtimensec;
-	uint32_t	ctimensec;
-	uint32_t	mode;
-	uint32_t	nlink;
-	uint32_t	uid;
-	uint32_t	gid;
-	uint32_t	rdev;
-	uint32_t	blksize;
-	uint32_t	flags;
+	__u64	ino;
+	__u64	size;
+	__u64	blocks;
+	__u64	atime;
+	__u64	mtime;
+	__u64	ctime;
+	__u32	atimensec;
+	__u32	mtimensec;
+	__u32	ctimensec;
+	__u32	mode;
+	__u32	nlink;
+	__u32	uid;
+	__u32	gid;
+	__u32	rdev;
+	__u32	blksize;
+	__u32	flags;
 };
 
 /*
@@ -307,53 +319,53 @@ struct fuse_attr {
  * Linux.
  */
 struct fuse_sx_time {
-	int64_t		tv_sec;
-	uint32_t	tv_nsec;
-	int32_t		__reserved;
+	__s64	tv_sec;
+	__u32	tv_nsec;
+	__s32	__reserved;
 };
 
 struct fuse_statx {
-	uint32_t	mask;
-	uint32_t	blksize;
-	uint64_t	attributes;
-	uint32_t	nlink;
-	uint32_t	uid;
-	uint32_t	gid;
-	uint16_t	mode;
-	uint16_t	__spare0[1];
-	uint64_t	ino;
-	uint64_t	size;
-	uint64_t	blocks;
-	uint64_t	attributes_mask;
+	__u32	mask;
+	__u32	blksize;
+	__u64	attributes;
+	__u32	nlink;
+	__u32	uid;
+	__u32	gid;
+	__u16	mode;
+	__u16	__spare0[1];
+	__u64	ino;
+	__u64	size;
+	__u64	blocks;
+	__u64	attributes_mask;
 	struct fuse_sx_time	atime;
 	struct fuse_sx_time	btime;
 	struct fuse_sx_time	ctime;
 	struct fuse_sx_time	mtime;
-	uint32_t	rdev_major;
-	uint32_t	rdev_minor;
-	uint32_t	dev_major;
-	uint32_t	dev_minor;
-	uint64_t	__spare2[14];
+	__u32	rdev_major;
+	__u32	rdev_minor;
+	__u32	dev_major;
+	__u32	dev_minor;
+	__u64	__spare2[14];
 };
 
 struct fuse_kstatfs {
-	uint64_t	blocks;
-	uint64_t	bfree;
-	uint64_t	bavail;
-	uint64_t	files;
-	uint64_t	ffree;
-	uint32_t	bsize;
-	uint32_t	namelen;
-	uint32_t	frsize;
-	uint32_t	padding;
-	uint32_t	spare[6];
+	__u64	blocks;
+	__u64	bfree;
+	__u64	bavail;
+	__u64	files;
+	__u64	ffree;
+	__u32	bsize;
+	__u32	namelen;
+	__u32	frsize;
+	__u32	padding;
+	__u32	spare[6];
 };
 
 struct fuse_file_lock {
-	uint64_t	start;
-	uint64_t	end;
-	uint32_t	type;
-	uint32_t	pid; /* tgid */
+	__u64	start;
+	__u64	end;
+	__u32	type;
+	__u32	pid; /* tgid */
 };
 
 /**
@@ -690,165 +702,165 @@ enum fuse_notify_code {
 #define FUSE_COMPAT_ENTRY_OUT_SIZE 120
 
 struct fuse_entry_out {
-	uint64_t	nodeid;		/* Inode ID */
-	uint64_t	generation;	/* Inode generation: nodeid:gen must
-					   be unique for the fs's lifetime */
-	uint64_t	entry_valid;	/* Cache timeout for the name */
-	uint64_t	attr_valid;	/* Cache timeout for the attributes */
-	uint32_t	entry_valid_nsec;
-	uint32_t	attr_valid_nsec;
+	__u64	nodeid;		/* Inode ID */
+	__u64	generation;	/* Inode generation: nodeid:gen must
+				   be unique for the fs's lifetime */
+	__u64	entry_valid;	/* Cache timeout for the name */
+	__u64	attr_valid;	/* Cache timeout for the attributes */
+	__u32	entry_valid_nsec;
+	__u32	attr_valid_nsec;
 	struct fuse_attr attr;
 };
 
 struct fuse_forget_in {
-	uint64_t	nlookup;
+	__u64	nlookup;
 };
 
 struct fuse_forget_one {
-	uint64_t	nodeid;
-	uint64_t	nlookup;
+	__u64	nodeid;
+	__u64	nlookup;
 };
 
 struct fuse_batch_forget_in {
-	uint32_t	count;
-	uint32_t	dummy;
+	__u32	count;
+	__u32	dummy;
 };
 
 struct fuse_getattr_in {
-	uint32_t	getattr_flags;
-	uint32_t	dummy;
-	uint64_t	fh;
+	__u32	getattr_flags;
+	__u32	dummy;
+	__u64	fh;
 };
 
 #define FUSE_COMPAT_ATTR_OUT_SIZE 96
 
 struct fuse_attr_out {
-	uint64_t	attr_valid;	/* Cache timeout for the attributes */
-	uint32_t	attr_valid_nsec;
-	uint32_t	dummy;
+	__u64	attr_valid;	/* Cache timeout for the attributes */
+	__u32	attr_valid_nsec;
+	__u32	dummy;
 	struct fuse_attr attr;
 };
 
 struct fuse_statx_in {
-	uint32_t	getattr_flags;
-	uint32_t	reserved;
-	uint64_t	fh;
-	uint32_t	sx_flags;
-	uint32_t	sx_mask;
+	__u32	getattr_flags;
+	__u32	reserved;
+	__u64	fh;
+	__u32	sx_flags;
+	__u32	sx_mask;
 };
 
 struct fuse_statx_out {
-	uint64_t	attr_valid;	/* Cache timeout for the attributes */
-	uint32_t	attr_valid_nsec;
-	uint32_t	flags;
-	uint64_t	spare[2];
+	__u64	attr_valid;	/* Cache timeout for the attributes */
+	__u32	attr_valid_nsec;
+	__u32	flags;
+	__u64	spare[2];
 	struct fuse_statx stat;
 };
 
 #define FUSE_COMPAT_MKNOD_IN_SIZE 8
 
 struct fuse_mknod_in {
-	uint32_t	mode;
-	uint32_t	rdev;
-	uint32_t	umask;
-	uint32_t	padding;
+	__u32	mode;
+	__u32	rdev;
+	__u32	umask;
+	__u32	padding;
 };
 
 struct fuse_mkdir_in {
-	uint32_t	mode;
-	uint32_t	umask;
+	__u32	mode;
+	__u32	umask;
 };
 
 struct fuse_rename_in {
-	uint64_t	newdir;
+	__u64	newdir;
 };
 
 struct fuse_rename2_in {
-	uint64_t	newdir;
-	uint32_t	flags;
-	uint32_t	padding;
+	__u64	newdir;
+	__u32	flags;
+	__u32	padding;
 };
 
 struct fuse_link_in {
-	uint64_t	oldnodeid;
+	__u64	oldnodeid;
 };
 
 struct fuse_setattr_in {
-	uint32_t	valid;
-	uint32_t	padding;
-	uint64_t	fh;
-	uint64_t	size;
-	uint64_t	lock_owner;
-	uint64_t	atime;
-	uint64_t	mtime;
-	uint64_t	ctime;
-	uint32_t	atimensec;
-	uint32_t	mtimensec;
-	uint32_t	ctimensec;
-	uint32_t	mode;
-	uint32_t	unused4;
-	uint32_t	uid;
-	uint32_t	gid;
-	uint32_t	unused5;
+	__u32	valid;
+	__u32	padding;
+	__u64	fh;
+	__u64	size;
+	__u64	lock_owner;
+	__u64	atime;
+	__u64	mtime;
+	__u64	ctime;
+	__u32	atimensec;
+	__u32	mtimensec;
+	__u32	ctimensec;
+	__u32	mode;
+	__u32	unused4;
+	__u32	uid;
+	__u32	gid;
+	__u32	unused5;
 };
 
 struct fuse_open_in {
-	uint32_t	flags;
-	uint32_t	open_flags;	/* FUSE_OPEN_... */
+	__u32	flags;
+	__u32	open_flags;	/* FUSE_OPEN_... */
 };
 
 struct fuse_create_in {
-	uint32_t	flags;
-	uint32_t	mode;
-	uint32_t	umask;
-	uint32_t	open_flags;	/* FUSE_OPEN_... */
+	__u32	flags;
+	__u32	mode;
+	__u32	umask;
+	__u32	open_flags;	/* FUSE_OPEN_... */
 };
 
 struct fuse_open_out {
-	uint64_t	fh;
-	uint32_t	open_flags;
-	int32_t		backing_id;
+	__u64	fh;
+	__u32	open_flags;
+	__s32	backing_id;
 };
 
 struct fuse_release_in {
-	uint64_t	fh;
-	uint32_t	flags;
-	uint32_t	release_flags;
-	uint64_t	lock_owner;
+	__u64	fh;
+	__u32	flags;
+	__u32	release_flags;
+	__u64	lock_owner;
 };
 
 struct fuse_flush_in {
-	uint64_t	fh;
-	uint32_t	unused;
-	uint32_t	padding;
-	uint64_t	lock_owner;
+	__u64	fh;
+	__u32	unused;
+	__u32	padding;
+	__u64	lock_owner;
 };
 
 struct fuse_read_in {
-	uint64_t	fh;
-	uint64_t	offset;
-	uint32_t	size;
-	uint32_t	read_flags;
-	uint64_t	lock_owner;
-	uint32_t	flags;
-	uint32_t	padding;
+	__u64	fh;
+	__u64	offset;
+	__u32	size;
+	__u32	read_flags;
+	__u64	lock_owner;
+	__u32	flags;
+	__u32	padding;
 };
 
 #define FUSE_COMPAT_WRITE_IN_SIZE 24
 
 struct fuse_write_in {
-	uint64_t	fh;
-	uint64_t	offset;
-	uint32_t	size;
-	uint32_t	write_flags;
-	uint64_t	lock_owner;
-	uint32_t	flags;
-	uint32_t	padding;
+	__u64	fh;
+	__u64	offset;
+	__u32	size;
+	__u32	write_flags;
+	__u64	lock_owner;
+	__u32	flags;
+	__u32	padding;
 };
 
 struct fuse_write_out {
-	uint32_t	size;
-	uint32_t	padding;
+	__u32	size;
+	__u32	padding;
 };
 
 #define FUSE_COMPAT_STATFS_SIZE 48
@@ -858,36 +870,36 @@ struct fuse_statfs_out {
 };
 
 struct fuse_fsync_in {
-	uint64_t	fh;
-	uint32_t	fsync_flags;
-	uint32_t	padding;
+	__u64	fh;
+	__u32	fsync_flags;
+	__u32	padding;
 };
 
 #define FUSE_COMPAT_SETXATTR_IN_SIZE 8
 
 struct fuse_setxattr_in {
-	uint32_t	size;
-	uint32_t	flags;
-	uint32_t	setxattr_flags;
-	uint32_t	padding;
+	__u32	size;
+	__u32	flags;
+	__u32	setxattr_flags;
+	__u32	padding;
 };
 
 struct fuse_getxattr_in {
-	uint32_t	size;
-	uint32_t	padding;
+	__u32	size;
+	__u32	padding;
 };
 
 struct fuse_getxattr_out {
-	uint32_t	size;
-	uint32_t	padding;
+	__u32	size;
+	__u32	padding;
 };
 
 struct fuse_lk_in {
-	uint64_t	fh;
-	uint64_t	owner;
+	__u64	fh;
+	__u64	owner;
 	struct fuse_file_lock lk;
-	uint32_t	lk_flags;
-	uint32_t	padding;
+	__u32	lk_flags;
+	__u32	padding;
 };
 
 struct fuse_lk_out {
@@ -895,117 +907,117 @@ struct fuse_lk_out {
 };
 
 struct fuse_access_in {
-	uint32_t	mask;
-	uint32_t	padding;
+	__u32	mask;
+	__u32	padding;
 };
 
 struct fuse_init_in {
-	uint32_t	major;
-	uint32_t	minor;
-	uint32_t	max_readahead;
-	uint32_t	flags;
-	uint32_t	flags2;
-	uint32_t	unused[11];
+	__u32	major;
+	__u32	minor;
+	__u32	max_readahead;
+	__u32	flags;
+	__u32	flags2;
+	__u32	unused[11];
 };
 
 #define FUSE_COMPAT_INIT_OUT_SIZE 8
 #define FUSE_COMPAT_22_INIT_OUT_SIZE 24
 
 struct fuse_init_out {
-	uint32_t	major;
-	uint32_t	minor;
-	uint32_t	max_readahead;
-	uint32_t	flags;
-	uint16_t	max_background;
-	uint16_t	congestion_threshold;
-	uint32_t	max_write;
-	uint32_t	time_gran;
-	uint16_t	max_pages;
-	uint16_t	map_alignment;
-	uint32_t	flags2;
-	uint32_t	max_stack_depth;
-	uint16_t	request_timeout;
-	uint16_t	unused[11];
+	__u32	major;
+	__u32	minor;
+	__u32	max_readahead;
+	__u32	flags;
+	__u16	max_background;
+	__u16	congestion_threshold;
+	__u32	max_write;
+	__u32	time_gran;
+	__u16	max_pages;
+	__u16	map_alignment;
+	__u32	flags2;
+	__u32	max_stack_depth;
+	__u16	request_timeout;
+	__u16	unused[11];
 };
 
 #define CUSE_INIT_INFO_MAX 4096
 
 struct cuse_init_in {
-	uint32_t	major;
-	uint32_t	minor;
-	uint32_t	unused;
-	uint32_t	flags;
+	__u32	major;
+	__u32	minor;
+	__u32	unused;
+	__u32	flags;
 };
 
 struct cuse_init_out {
-	uint32_t	major;
-	uint32_t	minor;
-	uint32_t	unused;
-	uint32_t	flags;
-	uint32_t	max_read;
-	uint32_t	max_write;
-	uint32_t	dev_major;		/* chardev major */
-	uint32_t	dev_minor;		/* chardev minor */
-	uint32_t	spare[10];
+	__u32	major;
+	__u32	minor;
+	__u32	unused;
+	__u32	flags;
+	__u32	max_read;
+	__u32	max_write;
+	__u32	dev_major;		/* chardev major */
+	__u32	dev_minor;		/* chardev minor */
+	__u32	spare[10];
 };
 
 struct fuse_interrupt_in {
-	uint64_t	unique;
+	__u64	unique;
 };
 
 struct fuse_bmap_in {
-	uint64_t	block;
-	uint32_t	blocksize;
-	uint32_t	padding;
+	__u64	block;
+	__u32	blocksize;
+	__u32	padding;
 };
 
 struct fuse_bmap_out {
-	uint64_t	block;
+	__u64	block;
 };
 
 struct fuse_ioctl_in {
-	uint64_t	fh;
-	uint32_t	flags;
-	uint32_t	cmd;
-	uint64_t	arg;
-	uint32_t	in_size;
-	uint32_t	out_size;
+	__u64	fh;
+	__u32	flags;
+	__u32	cmd;
+	__u64	arg;
+	__u32	in_size;
+	__u32	out_size;
 };
 
 struct fuse_ioctl_iovec {
-	uint64_t	base;
-	uint64_t	len;
+	__u64	base;
+	__u64	len;
 };
 
 struct fuse_ioctl_out {
-	int32_t		result;
-	uint32_t	flags;
-	uint32_t	in_iovs;
-	uint32_t	out_iovs;
+	__s32	result;
+	__u32	flags;
+	__u32	in_iovs;
+	__u32	out_iovs;
 };
 
 struct fuse_poll_in {
-	uint64_t	fh;
-	uint64_t	kh;
-	uint32_t	flags;
-	uint32_t	events;
+	__u64	fh;
+	__u64	kh;
+	__u32	flags;
+	__u32	events;
 };
 
 struct fuse_poll_out {
-	uint32_t	revents;
-	uint32_t	padding;
+	__u32	revents;
+	__u32	padding;
 };
 
 struct fuse_notify_poll_wakeup_out {
-	uint64_t	kh;
+	__u64	kh;
 };
 
 struct fuse_fallocate_in {
-	uint64_t	fh;
-	uint64_t	offset;
-	uint64_t	length;
-	uint32_t	mode;
-	uint32_t	padding;
+	__u64	fh;
+	__u64	offset;
+	__u64	length;
+	__u32	mode;
+	__u32	padding;
 };
 
 /**
@@ -1029,37 +1041,37 @@ struct fuse_fallocate_in {
  * FUSE_MKNOD, FUSE_SYMLINK, FUSE_MKDIR, FUSE_TMPFILE,
  * FUSE_CREATE and FUSE_RENAME2 (with RENAME_WHITEOUT).
  */
-#define FUSE_INVALID_UIDGID ((uint32_t)(-1))
+#define FUSE_INVALID_UIDGID ((__u32)(-1))
 
 struct fuse_in_header {
-	uint32_t	len;
-	uint32_t	opcode;
-	uint64_t	unique;
-	uint64_t	nodeid;
-	uint32_t	uid;
-	uint32_t	gid;
-	uint32_t	pid;
-	uint16_t	total_extlen; /* length of extensions in 8byte units */
-	uint16_t	padding;
+	__u32	len;
+	__u32	opcode;
+	__u64	unique;
+	__u64	nodeid;
+	__u32	uid;
+	__u32	gid;
+	__u32	pid;
+	__u16	total_extlen; /* length of extensions in 8byte units */
+	__u16	padding;
 };
 
 struct fuse_out_header {
-	uint32_t	len;
-	int32_t		error;
-	uint64_t	unique;
+	__u32	len;
+	__s32	error;
+	__u64	unique;
 };
 
 struct fuse_dirent {
-	uint64_t	ino;
-	uint64_t	off;
-	uint32_t	namelen;
-	uint32_t	type;
+	__u64	ino;
+	__u64	off;
+	__u32	namelen;
+	__u32	type;
 	char name[];
 };
 
 /* Align variable length records to 64bit boundary */
 #define FUSE_REC_ALIGN(x) \
-	(((x) + sizeof(uint64_t) - 1) & ~(sizeof(uint64_t) - 1))
+	(((x) + sizeof(__u64) - 1) & ~(sizeof(__u64) - 1))
 
 #define FUSE_NAME_OFFSET offsetof(struct fuse_dirent, name)
 #define FUSE_DIRENT_ALIGN(x) FUSE_REC_ALIGN(x)
@@ -1077,127 +1089,127 @@ struct fuse_direntplus {
 	FUSE_DIRENT_ALIGN(FUSE_NAME_OFFSET_DIRENTPLUS + (d)->dirent.namelen)
 
 struct fuse_notify_inval_inode_out {
-	uint64_t	ino;
-	int64_t		off;
-	int64_t		len;
+	__u64	ino;
+	__s64	off;
+	__s64	len;
 };
 
 struct fuse_notify_inval_entry_out {
-	uint64_t	parent;
-	uint32_t	namelen;
-	uint32_t	flags;
+	__u64	parent;
+	__u32	namelen;
+	__u32	flags;
 };
 
 struct fuse_notify_delete_out {
-	uint64_t	parent;
-	uint64_t	child;
-	uint32_t	namelen;
-	uint32_t	padding;
+	__u64	parent;
+	__u64	child;
+	__u32	namelen;
+	__u32	padding;
 };
 
 struct fuse_notify_store_out {
-	uint64_t	nodeid;
-	uint64_t	offset;
-	uint32_t	size;
-	uint32_t	padding;
+	__u64	nodeid;
+	__u64	offset;
+	__u32	size;
+	__u32	padding;
 };
 
 struct fuse_notify_retrieve_out {
-	uint64_t	notify_unique;
-	uint64_t	nodeid;
-	uint64_t	offset;
-	uint32_t	size;
-	uint32_t	padding;
+	__u64	notify_unique;
+	__u64	nodeid;
+	__u64	offset;
+	__u32	size;
+	__u32	padding;
 };
 
 /* Matches the size of fuse_write_in */
 struct fuse_notify_retrieve_in {
-	uint64_t	dummy1;
-	uint64_t	offset;
-	uint32_t	size;
-	uint32_t	dummy2;
-	uint64_t	dummy3;
-	uint64_t	dummy4;
+	__u64	dummy1;
+	__u64	offset;
+	__u32	size;
+	__u32	dummy2;
+	__u64	dummy3;
+	__u64	dummy4;
 };
 
 struct fuse_notify_prune_out {
-	uint32_t	count;
-	uint32_t	padding;
-	uint64_t	spare;
+	__u32	count;
+	__u32	padding;
+	__u64	spare;
 };
 
 struct fuse_backing_map {
-	int32_t		fd;
-	uint32_t	flags;
-	uint64_t	padding;
+	__s32	fd;
+	__u32	flags;
+	__u64	padding;
 };
 
 /* Device ioctls: */
 #define FUSE_DEV_IOC_MAGIC		229
-#define FUSE_DEV_IOC_CLONE		_IOR(FUSE_DEV_IOC_MAGIC, 0, uint32_t)
+#define FUSE_DEV_IOC_CLONE		_IOR(FUSE_DEV_IOC_MAGIC, 0, __u32)
 #define FUSE_DEV_IOC_BACKING_OPEN	_IOW(FUSE_DEV_IOC_MAGIC, 1, \
 					     struct fuse_backing_map)
-#define FUSE_DEV_IOC_BACKING_CLOSE	_IOW(FUSE_DEV_IOC_MAGIC, 2, uint32_t)
+#define FUSE_DEV_IOC_BACKING_CLOSE	_IOW(FUSE_DEV_IOC_MAGIC, 2, __u32)
 #define FUSE_DEV_IOC_SYNC_INIT		_IO(FUSE_DEV_IOC_MAGIC, 3)
 
 struct fuse_lseek_in {
-	uint64_t	fh;
-	uint64_t	offset;
-	uint32_t	whence;
-	uint32_t	padding;
+	__u64	fh;
+	__u64	offset;
+	__u32	whence;
+	__u32	padding;
 };
 
 struct fuse_lseek_out {
-	uint64_t	offset;
+	__u64	offset;
 };
 
 struct fuse_copy_file_range_in {
-	uint64_t	fh_in;
-	uint64_t	off_in;
-	uint64_t	nodeid_out;
-	uint64_t	fh_out;
-	uint64_t	off_out;
-	uint64_t	len;
-	uint64_t	flags;
+	__u64	fh_in;
+	__u64	off_in;
+	__u64	nodeid_out;
+	__u64	fh_out;
+	__u64	off_out;
+	__u64	len;
+	__u64	flags;
 };
 
 /* For FUSE_COPY_FILE_RANGE_64 */
 struct fuse_copy_file_range_out {
-	uint64_t	bytes_copied;
+	__u64	bytes_copied;
 };
 
 #define FUSE_SETUPMAPPING_FLAG_WRITE (1ull << 0)
 #define FUSE_SETUPMAPPING_FLAG_READ (1ull << 1)
 struct fuse_setupmapping_in {
 	/* An already open handle */
-	uint64_t	fh;
+	__u64	fh;
 	/* Offset into the file to start the mapping */
-	uint64_t	foffset;
+	__u64	foffset;
 	/* Length of mapping required */
-	uint64_t	len;
+	__u64	len;
 	/* Flags, FUSE_SETUPMAPPING_FLAG_* */
-	uint64_t	flags;
+	__u64	flags;
 	/* Offset in Memory Window */
-	uint64_t	moffset;
+	__u64	moffset;
 };
 
 struct fuse_removemapping_in {
 	/* number of fuse_removemapping_one follows */
-	uint32_t        count;
+	__u32	count;
 };
 
 struct fuse_removemapping_one {
 	/* Offset into the dax window start the unmapping */
-	uint64_t        moffset;
+	__u64	moffset;
 	/* Length of mapping required */
-	uint64_t	len;
+	__u64	len;
 };
 
 #define FUSE_REMOVEMAPPING_MAX_ENTRY   \
 		(PAGE_SIZE / sizeof(struct fuse_removemapping_one))
 
 struct fuse_syncfs_in {
-	uint64_t	padding;
+	__u64	padding;
 };
 
 /*
@@ -1207,8 +1219,8 @@ struct fuse_syncfs_in {
  * fuse_secctx, name, context
  */
 struct fuse_secctx {
-	uint32_t	size;
-	uint32_t	padding;
+	__u32	size;
+	__u32	padding;
 };
 
 /*
@@ -1218,8 +1230,8 @@ struct fuse_secctx {
  *
  */
 struct fuse_secctx_header {
-	uint32_t	size;
-	uint32_t	nr_secctx;
+	__u32	size;
+	__u32	nr_secctx;
 };
 
 /**
@@ -1231,8 +1243,8 @@ struct fuse_secctx_header {
  * FUSE_MAX_NR_SECCTX
  */
 struct fuse_ext_header {
-	uint32_t	size;
-	uint32_t	type;
+	__u32	size;
+	__u32	type;
 };
 
 /**
@@ -1241,8 +1253,8 @@ struct fuse_ext_header {
  * @groups: flexible array of group IDs
  */
 struct fuse_supp_groups {
-	uint32_t	nr_groups;
-	uint32_t	groups[];
+	__u32	nr_groups;
+	__u32	groups[];
 };
 
 /**
@@ -1253,19 +1265,19 @@ struct fuse_supp_groups {
 
 /* Used as part of the fuse_uring_req_header */
 struct fuse_uring_ent_in_out {
-	uint64_t flags;
+	__u64 flags;
 
 	/*
 	 * commit ID to be used in a reply to a ring request (see also
 	 * struct fuse_uring_cmd_req)
 	 */
-	uint64_t commit_id;
+	__u64 commit_id;
 
 	/* size of user payload buffer */
-	uint32_t payload_sz;
-	uint32_t padding;
+	__u32 payload_sz;
+	__u32 padding;
 
-	uint64_t reserved;
+	__u64 reserved;
 };
 
 /**
@@ -1298,14 +1310,14 @@ enum fuse_uring_cmd {
  * In the 80B command area of the SQE.
  */
 struct fuse_uring_cmd_req {
-	uint64_t flags;
+	__u64	flags;
 
 	/* entry identifier for commits */
-	uint64_t commit_id;
+	__u64	commit_id;
 
 	/* queue the command is for (queue index) */
-	uint16_t qid;
-	uint8_t padding[6];
+	__u16	qid;
+	__u8	padding[6];
 };
 
 #endif /* _LINUX_FUSE_H */

---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251222-uapi-fuse-1acdfb5abf77

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

On Tue, 30 Dec 2025 at 13:11, Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
>
> Using libc types and headers from the UAPI headers is problematic as it
> introduces a dependency on a full C toolchain.

Can you please elaborate?

Is there a real use case that is being fixed by this?

Or is this some theoretical thing?

Thanks,
Miklos

On 12/30/25 13:10, Thomas Weißschuh wrote:
> Using libc types and headers from the UAPI headers is problematic as it
> introduces a dependency on a full C toolchain.
> 
> Use the fixed-width integer types provided by the UAPI headers instead.
> To keep compatibility with non-Linux platforms, add a stdint.h fallback.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> Changes in v2:
> - Fix structure member alignments
> - Keep compatibility with non-Linux platforms
> - Link to v1: https://lore.kernel.org/r/20251222-uapi-fuse-v1-1-85a61b87baa0@linutronix.de
> ---
>  include/uapi/linux/fuse.h | 626 +++++++++++++++++++++++-----------------------
>  1 file changed, 319 insertions(+), 307 deletions(-)

I tested this and it breaks libfuse compilation

https://github.com/libfuse/libfuse/pull/1410

Any chance you could test libfuse compilation for v3? Easiest way is to
copy it to <libfuse>/include/fuse_kernel.h and then create PR. That
includes a BSD test.


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.


Thanks,
Bernd

On Fri, 2 Jan 2026 23:27:16 +0100
Bernd Schubert <bernd@bsbernd.com> wrote:

> On 12/30/25 13:10, Thomas Weißschuh wrote:
> > Using libc types and headers from the UAPI headers is problematic as it
> > introduces a dependency on a full C toolchain.
> > 
> > Use the fixed-width integer types provided by the UAPI headers instead.
> > To keep compatibility with non-Linux platforms, add a stdint.h fallback.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> > Changes in v2:
> > - Fix structure member alignments
> > - Keep compatibility with non-Linux platforms
> > - Link to v1: https://lore.kernel.org/r/20251222-uapi-fuse-v1-1-85a61b87baa0@linutronix.de
> > ---
> >  include/uapi/linux/fuse.h | 626 +++++++++++++++++++++++-----------------------
> >  1 file changed, 319 insertions(+), 307 deletions(-)  
> 
> I tested this and it breaks libfuse compilation
> 
> https://github.com/libfuse/libfuse/pull/1410
> 
> Any chance you could test libfuse compilation for v3? Easiest way is to
> copy it to <libfuse>/include/fuse_kernel.h and then create PR. That
> includes a BSD test.
> 
> 
> 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.

Or use 'unsigned long long' for the 64bit values and %llu for the format.
I'm pretty sure that works for all reasonable modern architectures.

You might still want to use the fuse_[us][8|16|32|64] names but they
can be defined directly as char/short/int/long long.

	David


> 
> 
> Thanks,
> Bernd
> 

On 1/3/26 15:10, David Laight wrote:
> On Fri, 2 Jan 2026 23:27:16 +0100
> Bernd Schubert <bernd@bsbernd.com> wrote:
> 
>> On 12/30/25 13:10, Thomas Weißschuh wrote:
>>> Using libc types and headers from the UAPI headers is problematic as it
>>> introduces a dependency on a full C toolchain.
>>>
>>> Use the fixed-width integer types provided by the UAPI headers instead.
>>> To keep compatibility with non-Linux platforms, add a stdint.h fallback.
>>>
>>> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>>> ---
>>> Changes in v2:
>>> - Fix structure member alignments
>>> - Keep compatibility with non-Linux platforms
>>> - Link to v1: https://lore.kernel.org/r/20251222-uapi-fuse-v1-1-85a61b87baa0@linutronix.de
>>> ---
>>>  include/uapi/linux/fuse.h | 626 +++++++++++++++++++++++-----------------------
>>>  1 file changed, 319 insertions(+), 307 deletions(-)  
>>
>> I tested this and it breaks libfuse compilation
>>
>> https://github.com/libfuse/libfuse/pull/1410
>>
>> Any chance you could test libfuse compilation for v3? Easiest way is to
>> copy it to <libfuse>/include/fuse_kernel.h and then create PR. That
>> includes a BSD test.
>>
>>
>> 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.
> 
> Or use 'unsigned long long' for the 64bit values and %llu for the format.
> I'm pretty sure that works for all reasonable modern architectures.
> 
> You might still want to use the fuse_[us][8|16|32|64] names but they
> can be defined directly as char/short/int/long long.

Well, what speaks against to it like I have done? A few more lines of
code, but even unlikely arch issues are excluded.

Thanks,
Bernd

On 1/2/26 23:27, Bernd Schubert wrote:
> 
> 
> On 12/30/25 13:10, Thomas Weißschuh wrote:
>> Using libc types and headers from the UAPI headers is problematic as it
>> introduces a dependency on a full C toolchain.
>>
>> Use the fixed-width integer types provided by the UAPI headers instead.
>> To keep compatibility with non-Linux platforms, add a stdint.h fallback.
>>
>> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>> ---
>> Changes in v2:
>> - Fix structure member alignments
>> - Keep compatibility with non-Linux platforms
>> - Link to v1: https://lore.kernel.org/r/20251222-uapi-fuse-v1-1-85a61b87baa0@linutronix.de
>> ---
>>  include/uapi/linux/fuse.h | 626 +++++++++++++++++++++++-----------------------
>>  1 file changed, 319 insertions(+), 307 deletions(-)
> 
> I tested this and it breaks libfuse compilation
> 
> https://github.com/libfuse/libfuse/pull/1410
> 
> Any chance you could test libfuse compilation for v3? Easiest way is to
> copy it to <libfuse>/include/fuse_kernel.h and then create PR. That
> includes a BSD test.
> 
> 
> 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.
> 

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


And then the rest of the file has to use the fuse_ types.


Thanks,
Bernd

On Sat, Jan 03, 2026 at 01:44:49PM +0100, Bernd Schubert wrote:
> 
> 
> On 1/2/26 23:27, Bernd Schubert wrote:
> > 
> > 
> > On 12/30/25 13:10, Thomas Weißschuh wrote:
> >> Using libc types and headers from the UAPI headers is problematic as it
> >> introduces a dependency on a full C toolchain.
> >>
> >> Use the fixed-width integer types provided by the UAPI headers instead.
> >> To keep compatibility with non-Linux platforms, add a stdint.h fallback.
> >>
> >> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> >> ---
> >> Changes in v2:
> >> - Fix structure member alignments
> >> - Keep compatibility with non-Linux platforms
> >> - Link to v1: https://lore.kernel.org/r/20251222-uapi-fuse-v1-1-85a61b87baa0@linutronix.de
> >> ---
> >>  include/uapi/linux/fuse.h | 626 +++++++++++++++++++++++-----------------------
> >>  1 file changed, 319 insertions(+), 307 deletions(-)
> > 
> > I tested this and it breaks libfuse compilation
> > 
> > https://github.com/libfuse/libfuse/pull/1410
> > 
> > Any chance you could test libfuse compilation for v3? Easiest way is to
> > copy it to <libfuse>/include/fuse_kernel.h and then create PR. That
> > includes a BSD test.

Ack.

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

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


Thomas

On 1/5/26 09:40, Thomas Weißschuh wrote:
> On Sat, Jan 03, 2026 at 01:44:49PM +0100, Bernd Schubert wrote:
>>
>>
>> On 1/2/26 23:27, Bernd Schubert wrote:
>>>
>>>
>>> On 12/30/25 13:10, Thomas Weißschuh wrote:
>>>> Using libc types and headers from the UAPI headers is problematic as it
>>>> introduces a dependency on a full C toolchain.
>>>>
>>>> Use the fixed-width integer types provided by the UAPI headers instead.
>>>> To keep compatibility with non-Linux platforms, add a stdint.h fallback.
>>>>
>>>> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>>>> ---
>>>> Changes in v2:
>>>> - Fix structure member alignments
>>>> - Keep compatibility with non-Linux platforms
>>>> - Link to v1: https://lore.kernel.org/r/20251222-uapi-fuse-v1-1-85a61b87baa0@linutronix.de
>>>> ---
>>>>  include/uapi/linux/fuse.h | 626 +++++++++++++++++++++++-----------------------
>>>>  1 file changed, 319 insertions(+), 307 deletions(-)
>>>
>>> I tested this and it breaks libfuse compilation
>>>
>>> https://github.com/libfuse/libfuse/pull/1410
>>>
>>> Any chance you could test libfuse compilation for v3? Easiest way is to
>>> copy it to <libfuse>/include/fuse_kernel.h and then create PR. That
>>> includes a BSD test.
> 
> Ack.
> 
>>> 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.
> 
>> 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.
Maybe you could explain your issue more detailed? I.e. how are you using
this include exactly?


Thanks,
Bernd

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

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.

Sorry for late reply, default Ubuntu x86_64 target.

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

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

Ack, I'll use this. Although I am not sure why uint64_t and __UINT64_TYPE__
should be guaranteed to be identical.

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

Ack.

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

Ack.


Thomas

On Fri, 9 Jan 2026 09:11:28 +0100
Thomas Weißschuh <thomas.weissschuh@linutronix.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.

	David

On 1/9/26 11:38, David Laight wrote:
> On Fri, 9 Jan 2026 09:11:28 +0100
> Thomas Weißschuh <thomas.weissschuh@linutronix.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.


The test PR from Thomas succeeds in compilation and build testing. Which
includes 32-bit cross compilation

https://github.com/libfuse/libfuse/pull/1417

Checkpatch complains a bit, but I would ignore that - I had mostly only
added checkpatch to ensure people are submitting with the right
formatting (lots of commits with spaces, but the project follows kernel
style).


Thanks,
Bernd1

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

On Fri, 9 Jan 2026 11:55:30 +0100
Thomas Weißschuh <thomas.weissschuh@linutronix.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@linutronix.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

On 1/9/26 14:11, David Laight wrote:
> On Fri, 9 Jan 2026 11:55:30 +0100
> Thomas Weißschuh <thomas.weissschuh@linutronix.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@linutronix.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.

Thanks,
Bernd

On Fri, 9 Jan 2026 14:46:02 +0100
Bernd Schubert <bernd@bsbernd.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@linutronix.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@linutronix.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

On 1/9/26 11:55, Thomas Weißschuh 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@linutronix.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.

I don't have a problem to adopt libfuse - that is the simple part. The
harder part are other fuse implementations that use the same header. And
they will complain to Miklos if compilation fails.
Which is why it is important that we catch beforehand as many issues as
we can and then the commit message should explain very detailed the use
case. I.e. if something breaks for others, we can still point to you use
case that would be broken without these changes.

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


I guess you can see why Miklos is resisting these changes without a good
use case :)


Thanks,
Bernd

On Mon, Jan 05, 2026 at 09:50:30AM +0100, 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:
> >>
> >>
> >> On 1/2/26 23:27, Bernd Schubert wrote:
> >>>
> >>>
> >>> On 12/30/25 13:10, Thomas Weißschuh wrote:
> >>>> Using libc types and headers from the UAPI headers is problematic as it
> >>>> introduces a dependency on a full C toolchain.
> >>>>
> >>>> Use the fixed-width integer types provided by the UAPI headers instead.
> >>>> To keep compatibility with non-Linux platforms, add a stdint.h fallback.
> >>>>
> >>>> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> >>>> ---
> >>>> Changes in v2:
> >>>> - Fix structure member alignments
> >>>> - Keep compatibility with non-Linux platforms
> >>>> - Link to v1: https://lore.kernel.org/r/20251222-uapi-fuse-v1-1-85a61b87baa0@linutronix.de
> >>>> ---
> >>>>  include/uapi/linux/fuse.h | 626 +++++++++++++++++++++++-----------------------
> >>>>  1 file changed, 319 insertions(+), 307 deletions(-)
> >>>
> >>> I tested this and it breaks libfuse compilation
> >>>
> >>> https://github.com/libfuse/libfuse/pull/1410
> >>>
> >>> Any chance you could test libfuse compilation for v3? Easiest way is to
> >>> copy it to <libfuse>/include/fuse_kernel.h and then create PR. That
> >>> includes a BSD test.
> > 
> > Ack.
> > 
> >>> 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.
> > 
> >> 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.

Yes, unfortunately.

> Maybe you could explain your issue more detailed? I.e. how are you using
> this include exactly?

I want the linux/fuse.h to work together with -nostdinc.

This has various advantages:
* It allows compilers for other languages to parse the C headers without
  the dependency on a full toolchain.
* It enables the usage in other, non-libc based C environments.
* Together with [0], it allows the verification of the header for all
  architectures. For example Arnd works on validating the UAPI against -Wpadded
  which requires the header to be built for each architecture.

This affected me at [1] and now I'm trying to proactively avoid this issue in
other places and prevent its re-introduction.

[0] https://lore.kernel.org/lkml/20251223-uapi-nostdinc-v1-0-d91545d794f7@linutronix.de/
[1] https://lore.kernel.org/lkml/20251203-uapi-fcntl-v1-1-490c67bf3425@linutronix.de/


Thomas

On Tue, Dec 30, 2025, at 13:10, Thomas Weißschuh wrote:
> Using libc types and headers from the UAPI headers is problematic as it
> introduces a dependency on a full C toolchain.
>
> Use the fixed-width integer types provided by the UAPI headers instead.
> To keep compatibility with non-Linux platforms, add a stdint.h fallback.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>