=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
workingjubilee wrote:
@pinskia I thought about that possibility, but I'm not sure how much it
matters, because it remains that now C code that works with a pointer to a
struct that looks like `{ int, bool }` can still "work" if `nonzero` is set, as
long as the original code that initialized the struct sets `0x00` for false and
*anything else* for `true`. Meanwhile, Rust will insist on `0x00` and `0x01` so
that types like `Option<bool>` can encode the "empty" `None` variant using an
unused bitpattern (like `0x02`, say), and we don't want to change the
representation of the contained scalar from "one of those two bitpatterns"
based on whether it's in an `Option` or not. When someone passes that pointer
from C to Rust, we won't know how that bitpattern was set, or even if it was
set by clang (or gcc!) for that matter, as all that really matters from the
"practical interop with implementations, not theoretical interop with the
standard" perspective is that we will have different codegen and treat the
value differently than the C compiler would.
https://github.com/llvm/llvm-project/pull/160790
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
