From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1648C2DF126 for ; Fri, 9 Jan 2026 10:38:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767955115; cv=none; b=XYrkoL38PpzHcWm/e/nRmPRRi+qJvlLvz3iYdIwsQwE6Ox/ZoG8vN5uWe4Q08XEcrY3hbLVP9tw2kTLx8qVGU1ZGSLJsiBquUnrLngqTwbejhJeaOI7mALO2b6zjbCAkBK8iUM240bXWtl5vndlPpSTzgDuTss1p8/rPHLvxNeU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767955115; c=relaxed/simple; bh=c+ZhJi0bXxqFuXDXgywqPB3RNPjIqKEqdODCPobZw6s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=r17SnH8G9b7XACvN+76+u9Dua46e8UnW9AlKrEpbVGQxbqBWTjkRxq17ncXI5blK/cXash/wC7eXC3UyN0NqRTccMFIU23ALrXOAQ1AOBb/PJIJE6dZqI1ziHDooozY2M30C0bQkOKBriTvCQD2zTTxLrHvmDCp+BK3REnFurUE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=W3OncSyU; arc=none smtp.client-ip=209.85.221.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="W3OncSyU" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-4327555464cso2362675f8f.1 for ; Fri, 09 Jan 2026 02:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767955112; x=1768559912; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=z80Y99EDQQAWvdag25MBGlQJoO8vUt97h03J11RRGQI=; b=W3OncSyU5fuNmRY2A0G2qHeaui7u7K9nEiEXwC1GZP7XqKc6I8uEXo8BrNWCCoCsF9 F17+jKVb+34VCOj7zKzyCr+GltUGO8dAIjgzDKNVcOT4yzFBSGweLx89b8dCybR5fYCj nl2pdhlIvZ5dsgUo05S72Vzl6QnY4gOvyFM4mZ+ijZqPreN1tRK8bvnHaeahtFerfyWi M0Z+wTVBK1XNZ5Z4sSWP/jUyysDgsJLIDm/OQjPmgY7nJG7b6UtSgk2zcjaiCFDeZ6rL UXtFkzVqmRC8BEwdnwjH1VHIW6zzrKrzo8xETYGaNKqLJlOqRv6JijGhU9mtsJ/W0YfJ UDMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767955112; x=1768559912; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=z80Y99EDQQAWvdag25MBGlQJoO8vUt97h03J11RRGQI=; b=pPZBFrgYfv/zjhYbN0yPx9VCLZE7cTH0Wr6mRTNEQx9V/sdeXtyxc0mb5rZLvkfRgD 25K6j/ERApFMIka2WklZq+BAd7UVqGdDZSXP5CYP1M+0eNLcXC38xAKRsV/zSfd5NKos BefuxWioQmWt/QDDJ3o+H/DXND53EUJ6Qz84xwyu9qXOm/2J/E0jmHI3lqWlyZsEj3cF 3rCYKjndx7NwGNWnwUeNMmiHZAyWCmYM/ONmGCd7qLBoS5v3xqJUcAMGep1wkPJxan+F ixs3AfC5eJtAwMJxHOD8fgB8ARlLbHVyg8j53IhfrD+aJ5pYX0e74LCZ/J58M0l/RPQH zY9Q== X-Forwarded-Encrypted: i=1; AJvYcCVyB9zmljxUah26uBwcegs01TOebgC8YNlA/RI9RqbLZVv4hNgkF+0aEbiRrDdomp/zxFSFnn+3C+aHsE4=@vger.kernel.org X-Gm-Message-State: AOJu0YxgutB+3kVxJxojTqNTVm2bJGNgDTTfnVgumHdqsn93xd3sxpzA 9w8rNEh+683PukA4D105u7+0bgn6g/8uYpHyQgvtsO1BUPuKu+9WOrkgARWoew== X-Gm-Gg: AY/fxX5G5aEtppjk/RBZ7Q7+OnBumsAIY+cXZy/vYkCDrBbHI/jYdd5EruDqQA6bmby Gs79tKGEXpb/MK1DdEbqytThx1kJb/SeddLGMq8ERlGIN1LEC3dhKzMLX8FYdTKFgryv0uxahYG IUHl+dM070yQLtA/zEz1msDk6JFxW2+K96nOEl+OK26QNTxRotHxAb5WS9N/byga+04HFFinA1s LxZfn5CFVQYRzO2V4qEuDNlNw76e4MUOceepWwHo2NbGsm2daGGQ9ec7jKvAYlleRE0mcfXrwLv 7Fga3cea2DVJj3CpaNG/RoUn/JgTJhQ9xsMUr/ujOKTGZ/Yd0me3jr2+me8FoNNQ0D1vRqgXlsi UFSHFx9dMh+QLfHAtetRLonGkZG6rqPvSj8i/hKYAWZMnvYL9nyr+uCsPWzs0RMTYqpmCpPW4Wf LRLCUkitMPpUgZxZzfwMlGlXDOLFGyYQ29WCbAzZiTiFEJgS4VV/DwKaT4NYvSp4M= X-Google-Smtp-Source: AGHT+IGoW+a8J/WoHD2PfbgH/34JdxcjznAC6FiDXmVAjsc1Fbs01hlM4un1BpydrdNwh9k2l1Ng/g== X-Received: by 2002:a05:6000:3104:b0:430:fdb8:850c with SMTP id ffacd0b85a97d-432c37c380cmr10699593f8f.61.1767955111819; Fri, 09 Jan 2026 02:38:31 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5df8besm20778549f8f.26.2026.01.09.02.38.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jan 2026 02:38:31 -0800 (PST) Date: Fri, 9 Jan 2026 10:38:27 +0000 From: David Laight To: Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= Cc: Bernd Schubert , Arnd Bergmann , Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] fuse: uapi: use UAPI types Message-ID: <20260109103827.1dc704f2@pumpkin> In-Reply-To: <20260109085917-e316ce57-5e78-4827-96d7-4a48a68aa752@linutronix.de> References: <20251230-uapi-fuse-v2-1-5a8788d62525@linutronix.de> <8efcbf41-7c74-4baf-9d75-1512f4f3fb03@bsbernd.com> <20260105092847-f05669a4-f8a1-498d-a8b4-dc1c5a0ac1f8@linutronix.de> <51731990-37fe-4821-9feb-7ee75829d3a0@bsbernd.com> <2c1dc014-e5aa-4c1d-a301-e10f47c74c7d@app.fastmail.com> <20260109085917-e316ce57-5e78-4827-96d7-4a48a68aa752@linutronix.de> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 9 Jan 2026 09:11:28 +0100 Thomas Wei=C3=9Fschuh wrote: > On Thu, Jan 08, 2026 at 11:12:29PM +0100, Bernd Schubert wrote: > >=20 > >=20 > > On 1/5/26 13:09, Arnd Bergmann wrote: =20 > > > On Mon, Jan 5, 2026, at 09:50, Bernd Schubert wrote: =20 ... > > > 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. > > >=20 > > > 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: > > >=20 > > > #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 > > > typedef uint64_t fuse_u64; > > > typedef int64_t fuse_s64; > > > typedef uint32_t fuse_u32; > > > typedef int32_t fuse_s32; > > > ... > > > #endif =20 > >=20 > > I personally like this version. =20 >=20 > 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) =3D=3D 4 && sizeof (fuse_u64) =3D=3D 8); And then use %x and %llx in the format strings. David