[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72kC-04zFPZ0c9wc=9MGRek4QnU_7o2E-H2VJjdCf+6GFw@mail.gmail.com>
Date: Sat, 14 Oct 2023 13:59:58 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: benno.lossin@...ton.me, boqun.feng@...il.com, tmgross@...ch.edu,
netdev@...r.kernel.org, rust-for-linux@...r.kernel.org, andrew@...n.ch,
greg@...ah.com
Subject: Re: [PATCH net-next v3 1/3] rust: core abstractions for network PHY drivers
On Fri, Oct 13, 2023 at 11:53 AM FUJITA Tomonori
<fujita.tomonori@...il.com> wrote:
>
> I'm not sure the general rules in Rust can be applied to linux kernel.
Benno and others already replied nicely to this, but I wanted to point
out that this happens with C compilers just the same. It is not a
"Rust thing" and what matters is what compilers do here, in practice.
For instance, you can try to compile this with GCC under -O2, and you
will get a program that returns a 2:
int main(void) {
_Bool b;
char c = 42;
memcpy(&b, &c, 1);
if (b)
return 43;
return 44;
}
Similarly, one for Rust where LLVM simply generates `ud2`:
#[repr(u32)]
pub enum E {
A = 0,
B = 1,
}
pub fn main() {
let e = unsafe { core::mem::transmute::<u32, E>(5) };
std::process::exit(match e {
E::A => 42,
E::B => 43,
});
}
The `e` variable is what we can get from C without an unsafe block if
you use `--rustified-enum`, i.e. the case in your abstractions.
The critical bit here is that, in C, it is not UB to have value 5 in
its enum, so we cannot rely on that.
Cheers,
Miguel
Powered by blists - more mailing lists