From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 C66FD320A20 for ; Wed, 21 Jan 2026 03:20:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768965627; cv=none; b=ffG9bx4mgftABcN9zxWg2Ksp66Nf18wsi+xT8GDxVTJv0AFovRV/0pOPzWOrmw9UBLDA/bBal/Gbd7mlrJOAbGuqh7UZwj/M1wBTcnZV1Z+cM7ROoVFY4rNXosEKGL0U59YQOt7yD0s8FeAsEP82GcuSuzvV+j959RVs78pfk+4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768965627; c=relaxed/simple; bh=jWQK8hz9bGTtCAsJhY5I94BjN1fB3IOX9lF9/VM4pro=; h=Mime-Version:Content-Type:Date:Message-Id:From:To:Cc:Subject: References:In-Reply-To; b=PDuE6NK7mkYQHNoUzf3RfRUXEcA9whXzkZocUSMQSqzSMFDvqsTIfIPgq3QEav7zLT9kiUB6nXZFobWw0snrvFXkP2/qErKX+W9WJ+M7ARwX71yrNSVI0O3f/5fbslR672L+rXxSeHP3Tw6ZPr5eXf846+z8pgrQwria4zmvhIc= 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=FhnyQWvy; arc=none smtp.client-ip=209.85.214.175 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="FhnyQWvy" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2a75a4a140eso8407005ad.3 for ; Tue, 20 Jan 2026 19:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768965625; x=1769570425; darn=vger.kernel.org; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ENJy6NtKsO9aQqhGsET5QqkuIFBDfe/xZv4HvwTdfk8=; b=FhnyQWvyp0sJLp6DjN71JV/w5dGbrGTTxw7XHxMT9mwoMrH9IMSAx1v1YEI1W+Kncb HHLBU3Km+I7nMoVLVUwZ3UXNWOW2AXzY/KJeTJ2vIkby+5olfHgOsvGYdWCbb8WtuAHk WCYuMcQpumwtQE2HoK2OeZzYLkEDa5nHF8X0GinXJ99pSiqCTHvhnRxA4otw/MUD/bPY JZ3TJ7vPkywzqyL+KVV9fvSCg2MNCLRc6xZHr7+COjNMDEKX5cK/RqEXlou45zuowzMN 0PeTVCMljYHAOtHpB+W3lWhn2vbF5H9g0Q4NYjqWzFfQADFhflL81h8fl9Sbny/MQKSm RLNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768965625; x=1769570425; h=in-reply-to:references:subject:cc:to:from:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ENJy6NtKsO9aQqhGsET5QqkuIFBDfe/xZv4HvwTdfk8=; b=v/IW/xQkrli0lxlgL1X1PgRgoYl6I09R5kOq9ThWS6sRaFHlxRM9Uy9VftbXSl+0d8 4pJR6Nl5YXinfpQDGrWuO+XohYmWD+0EZ7k6+zy9yF8VmZpZPSIFFNuubb+Sj5Im1T53 rGnO20CcolARYjh4UaxwWPhXNk8+WuL3E4ygjcOxTbuQ91pOMATMBAMXPy0mZ7o0H0vd nAwDdOAmNP/XfP6JQT0D5mAt6+id+WYA6qSqqyvZ5aJ7SMnfVwLwk68JKVt+jtlagu1Q nIXue460UEhhovKIB4Y18NpFw8ensWONL0Aq2s+vBsF6ly/+amctiRm1s1HN2D5MI+nK LNmQ== X-Forwarded-Encrypted: i=1; AJvYcCUlcRz4E3ks78fvqghRa6mP/iFTAABqnL9XemjwcGCm4/dBYCW9F91TlIy0nVBXvfRAtStvnZHh51kyVZ0=@vger.kernel.org X-Gm-Message-State: AOJu0YyGG7oPmC6DPpYRfQur+7T8gRG0fGPvhKRkDl/6ef0DQslv6UWR 5sBJhKdrEUlJ8Y15pTyZqb8gjlsC0p7D0cWSZb5uOmSFOifEAC9kVb0L X-Gm-Gg: AZuq6aKtN7hv5H7kEtHXAPElsIakAoTgKVlWXlBLFmh804VM3H4ARqbobu+Q10iwp+p 2cj/e6isq2Lh3moNJtxXFuAlWsEf+L2MWdXpJ0GcVaJnQ/PluFpEjDQhsAkUT2KGTpeBLsD69T5 WXyAHzwxobez+sJbUzFL5/6zbU+Gl7lVdTxU5uHjMazWQMDzzJYWuieLh6u6up8GjqBM7Kv0bgc noNfVDmcyVhgA54qSUWEPnVU4smzzVspIgHCWCqEkaeIaGcqwujK4oyv8X7e/tPbHpQaCR9yeqO c7n0b5yqLJn8PBQxY8lVSvC5M34tm9dwwRAiEzOPXaLzKHfCMFzO8x9kieLx7t+A4pvW/LWHTmi envIlDTVSqb/eY1WVUsCWvQ2dJVwtOJzQ/Yq3gl8CK5fXrkogvtn7tM4dm0g3Ei0pGYUItT70vY jQ3boMnA== X-Received: by 2002:a17:902:f689:b0:2a0:a92c:2cb6 with SMTP id d9443c01a7336-2a76ad6bb37mr36121375ad.36.1768965624996; Tue, 20 Jan 2026 19:20:24 -0800 (PST) Received: from localhost ([112.149.32.52]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2a773de1fe7sm28075635ad.82.2026.01.20.19.20.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jan 2026 19:20:24 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 21 Jan 2026 12:20:20 +0900 Message-Id: From: "Jesung Yang" To: "Benno Lossin" , "Jesung Yang" Cc: "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Danilo Krummrich" , "Alexandre Courbot" , , , Subject: Re: [PATCH v4 1/4] rust: macros: add derive macro for `Into` X-Mailer: aerc 0.21.0 References: <20251225-try-from-into-macro-v4-0-4a563d597836@gmail.com> <20251225-try-from-into-macro-v4-1-4a563d597836@gmail.com> In-Reply-To: OK, let me reignite this series... On Tue Dec 30, 2025 at 6:09 PM KST, Benno Lossin wrote: > On Mon Dec 29, 2025 at 1:29 PM CET, Jesung Yang wrote: >> On Sat, Dec 27, 2025 at 1:57=E2=80=AFPM Benno Lossin = wrote: [...] >> To sum up, I see three options: >> >> 1. Drop support for `#[repr(C)]` enums entirely. >> 2. Special-case `#[repr(C)]` enums: allow them to default to >> `isize`, otherwise require `#[repr({integer})]`. >> 3. Permit missing `#[repr({integer})]` generally. >> >> I am personally leaning toward Option 3, since our existing >> compile-time check provides a sufficient safety margin to allow this >> flexibility. >> >> Thoughts on these? > > Looking at the nomicon documentation [1] again, I found the following: > > repr(C) is equivalent to one of repr(u*) (see the next section) for > fieldless enums. The chosen size and sign is the default enum size > and sign for the target platform's C application binary interface > (ABI). Note that enum representation in C is implementation defined, > so this is really a "best guess". In particular, this may be > incorrect when the C code of interest is compiled with certain > flags. > > Which to me reads as "don't use `repr(C)`, if you want to know which > repr the enum gets". Especially the last part is concerning to me, as > the kernel uses lots of (bespoke) compiler flags. So I'm thinking we > should just drop `repr(C)` enum support. Any thoughts from others? > > [1]: https://doc.rust-lang.org/nomicon/other-reprs.html I think the last part you mentioned is less of a concern in this context, as this series does not introduce new FFI boundaries; `try_from` and `into` themselves live only on the Rust side and do not interact with the C side. We are indeed relying on Rust's "best guess" about the internal representation to perform compile-time checks, but these trait implementations do not pass enums across the boundary to C code. Your concern is certainly valid for anyone introducing new `#[repr(C)]` fieldless enums that interface with the C side (and we may want to revisit any existing ones). In our case, however, it should be safe as we ensure that discriminants do not overflow Rust's own internal representation of `#[repr(C)]` enums. Best regards, Jesung