From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (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 EC512299AAB for ; Tue, 4 Nov 2025 19:30:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762284624; cv=none; b=QpGE3FlqgQexhD2u4LpGWSGXiLFjFDzrLIWjp6YeroUjtufBpSTH4+iNDjd7GqHN7blkANClYwLdbCM9eLrx9IHccosTooH+iAxn/osNj3iCCVP3adNFVCq73x53zZAuOrSZc/9FTs3u2eq1ht0YnVGcdbOTq9J6bc1q2/nS0dw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762284624; c=relaxed/simple; bh=uYoW/8o2oWvHywWaopv1m5BZj9vCw8WNveRwCymRnA8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R+9wnT22kJhfgZnNCublUiNATWcqk1blcHsPAZy0trwcdUxTHUro5IDuK7H3ClT9C4r28kV42kDEpNhHvEAQyfOYgNi70YiqbvhYfd5FF8ZVoLhG1UIPM6F4Ed5F/bXD81pD7JMuk18iw7n9U3HH4qzn7G2VkLei283In68vOI0= 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=if1Kxuhz; arc=none smtp.client-ip=209.85.160.180 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="if1Kxuhz" Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-4ed0d2a949dso40473761cf.1 for ; Tue, 04 Nov 2025 11:30:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762284622; x=1762889422; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Yrkua1HDR61+GtT/9O/LrkaCogME0nTN9Kn1x1xYcQs=; b=if1Kxuhz7kOn3zCAHr23JnBpzwX9jQOzEIfzra22lGBmLZXjly/JMD3rOycw6efEXk WLmTjW60EotiMDg40iVrOg7LOQQGRx39YEjStsO0GsCW7PslWWBcU1DJM61wz3reADOl kunzY2RcyQ4cTg5iuWcZyabLvP0jBu/e9L9eWloNWwcvFoLbj6jGSj4mhKN1IYppzjUX WCudRpkCK77SMhepOClRKG6aVmFk1BA9t+g0Xr4J0jtBmCWYunjdyQgNth6qpEd07FFp xgw+R6bwHmcyJrbvtK7MeMS55pbzKtbBuWbvDXiincB50nFx/NQps2E/2jOAXiSlqSJU QzZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762284622; x=1762889422; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Yrkua1HDR61+GtT/9O/LrkaCogME0nTN9Kn1x1xYcQs=; b=svNmD1G0DrmeXP6NW/41/rYXRO4e4anHYdEKhB3uINr9jckHCMddsUBGn4mrJNxcLF GJGRs5Q5f3hSh1Zd5jCow5zRAnF4cixSzcMP3r/YUU9zwE+FpZQp8V7eFCSx0EiRpuLp UzESzooGESv48ru5mffORoPkCdCew6A4XFnpQp8JMB7U5MPQSLH90my8YRZxIRpVk2QF f9jw6hQFhPDFQNYLRdg/lZj8zXzGoFDDUj9B7M5WCIV8Mg0gsLnaWMY7iONKsDksryxx 4ebnRAj0FvQYVEZXvT0N7mY/1llbnYgofypwNN5Yqaija4I5jWrt3nE9Z+CBQEbRsa2b NRXg== X-Forwarded-Encrypted: i=1; AJvYcCXJ46ZDk/209nW6meoFpthUOP59pomhAb/J6hW9azS77dhS2B47UO9L3a+Ey/DQy0EWrraPBsfy4XdpTJNtTg==@vger.kernel.org X-Gm-Message-State: AOJu0Yyiyf7CeqbOeNOaUhlP0+E3BeWabUrF2GYTBUfcTFwJBUOSxrK6 Kr6XxrbQfuhdxBT3bsItcPkoB14+vvd3zqijef6qZ1jECMIBfvZWTMvC X-Gm-Gg: ASbGncvdYABpGfDyfg2bMgag43W/qLDWz4JoFCNn1UShsHJvTSCTE3EghyxZi2lIcSL BnFYZ+NS58+BtuR+TvFl4yrlRcCWlCMtqTNI0S7CTW3NVJVwc+904pMHks9722blESyiXq36Dql 57ezSBNbwbe6hKuI+3XiN7Q6zE7+Yww+S5t3xqNzDo7AcFJ2VBCLOliKkVMCG07Tjlc+iB9+gDI m0BmcLVg+blVV/fzaP2Dc8mBK1sGOkVwBPK8m+IUbCr+kjZJQ0vHFtScdrWAcbBsGF0gEFueH69 s6GEojFCIasE9nff+2nUC+pNLiSDbkggpDoZ2wrAMYvycowU+QULELo2UAJsugUOGriyBKqSFGc LwTAk5B5HWBGAZc4N/pqQY6dkpWrC/HTsLTEyXgjsG75PsB9QiZERYw3HqP9jgRn1Bp4P1/ZJa5 e13a1UXlY= X-Google-Smtp-Source: AGHT+IHHZ8QvW/CCOjhJABVz/T5Nuu/Qpdn9xw9nWT38C4aLePVGZ+lIedTnJOWnSxHq59U3rhqb6A== X-Received: by 2002:ac8:5d12:0:b0:4e8:b812:2e2a with SMTP id d75a77b69052e-4ed7237c610mr9079481cf.24.1762284621840; Tue, 04 Nov 2025 11:30:21 -0800 (PST) Received: from localhost ([12.22.141.131]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4ed5facb3efsm23437931cf.7.2025.11.04.11.30.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Nov 2025 11:30:21 -0800 (PST) Date: Tue, 4 Nov 2025 14:30:19 -0500 From: Yury Norov To: Alexandre Courbot Cc: Alice Ryhl , Danilo Krummrich , Miguel Ojeda , Joel Fernandes , Jesung Yang , Boqun Feng , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org Subject: Re: [PATCH 1/2] rust: add BitInt integer wrapping type Message-ID: References: <20251031-bounded_ints-v1-0-e2dbcd8fda71@nvidia.com> <20251031-bounded_ints-v1-1-e2dbcd8fda71@nvidia.com> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Nov 04, 2025 at 12:13:26PM +0900, Alexandre Courbot wrote: > On Tue Nov 4, 2025 at 4:36 AM JST, Yury Norov wrote: > > On Mon, Nov 03, 2025 at 10:42:13PM +0900, Alexandre Courbot wrote: > >> Hi Yury, ... > let a = BitInt::::new::<3>(); > let b = BitInt::::new::<123>() + a.cast::(); > > let c = a.cast::() + u32::from(b); > > Note that `b` and `c` are regular `u16` and `u32`. Arithmetic operations > cannot guarantee that the BitInt invariant will be maintained, so the > result needs to be converted back if that's what one wants. What C does and what I proposed is to make BitInt a 1st class type, just like basic integers. What you implement is really a bounded int. Both have advantages. C-style BitInt() is a true type with all type guarantees. And I like it more because it is a natural extension of the existing integer scheme. Your bounded ints are actually classical integers with some limitations. It's not a primitive type in sense of C - it's an object. It also works fine. You can easily extend it to arbitrary min and max limits; you can expand it to floating types, and do whatever you can do with the objects. BitInt(i32, -128, 255) BitFloat(f32, -1, 1) That's why you think that -1i32 fits into BitInt(i32, 4), and even into BitInt(i8, 4), while I don't. I don't know which would work better for bitfields. Most likely both would work reasonably well. And if bitfield will carefully hide internals, I hope most users will not care much. You switched name to BitInt, but still think about it as an object, and that brought all the confusion in my mind. Maybe switch back to BoundedInt then to avoid this confusion? If you find it lengthy, probably LimInt or simply Lint will be better for you. Looking at how good rust macros work to implement bitfields, I thought that they will be able to mimic native types just as well. But now it seems like an arbitrary-length integer types requires support on language side. Just like in C. With that in mind, I think that bounded integers are a bit out of scope of basic bit operations, and probably I'm not a right person to maintain them neither in Rust, nor in C. Please keep me in CC for next versions. Thanks, Yury