[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFJgqgTD-N=Gd7TRBD7N-5vuojq8nWffn-J91egoUP1stTFkhQ@mail.gmail.com>
Date: Thu, 27 Feb 2025 07:43:24 -0700
From: Ventura Jack <venturajack85@...il.com>
To: Gary Guo <gary@...yguo.net>
Cc: Kent Overstreet <kent.overstreet@...ux.dev>,
Linus Torvalds <torvalds@...ux-foundation.org>, Alice Ryhl <aliceryhl@...gle.com>, airlied@...il.com,
boqun.feng@...il.com, david.laight.linux@...il.com, ej@...i.de,
gregkh@...uxfoundation.org, hch@...radead.org, hpa@...or.com,
ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
miguel.ojeda.sandonis@...il.com, rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)
On Wed, Feb 26, 2025 at 1:33 PM Gary Guo <gary@...yguo.net> wrote:
>
>
> If you translate some random C code to all-unsafe Rust I think there's
> a good chance that it's (pedantically) undefined C code but well
> defined Rust code!
I do not believe that this holds all that often. If you look at the bug
reports for one C to Rust transpiler,
https://github.com/immunant/c2rust/issues
some of them have basic C code. A major issue is that C, especially
when "strict aliasing" is turned off through a compiler option,
often in code have aliasing, while unsafe Rust does not protect
against all aliasing and have stricter requirements in some
ways. So it can often be the case that the original C code has
no UB, but the transpiled unsafe Rust version has UB.
The blog posts.
https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/
also touch on this.
Best, VJ.
Powered by blists - more mailing lists