Document (for the purpose of education) cases where Rust gives unsafe code fewer guarantees than C/C++ code has come to rely on

[thomcc]

#292 gave me this idea, but is in some sense the opposite.

ISTM that a valuable addition for the purpose of education would be a set of cases where Rust differs from what C or C++ systems programmers expect, in the direction of patterns they expect to work to be either unreliable, or flat out UB.

Some examples of this are:

• Initialization invariant for integers.
• Things like Storing an object as &Header, but reading the data past the end of the header #256
• Provenance of references invalidating pointers.
• Etc.

This is tricky, since many of these are still in flux, and are things we might not want to actually commit to — however, documenting them is effectively committing to them...

P.S. sorry if this issue exists somewhere, I didn't see it.

[Lokathor]

I think it's fine enough to document "this is what the compiler does today but we might change it later"

[RalfJung]

Good idea!

Items 2 and 3 are fundamentally the same thing: Stacked Borrows (or whatever the final aliasing model for Rust will be).

Rust references also have an initialization invariant that does not match anything in C -- but then, C doesn't have anything even resembling that type. However, C++ has references, so it might make sense to compare those. To my knowledge, C++ references have to be dereferencable under some conditions even when not used (in particular, when they are passed to a function). But do they also have to be aligned? Also Rust likely requires dereferencability in more situations than C++ does.

[RalfJung]

Another thing to possibly add to the list: equality on function pointers (because we use "unstable address" for all functions). And maybe the same for vtables? Not sure what C++ does there; it also seems less relevant there since vtable ptrs do not affect ==.

[thomcc]

Items 2 and 3 are fundamentally the same thing: Stacked Borrows

Sure, but I think it might be better for the purposes of education to separate and explicitly mention some of the different consequences of stacked borrows.

As it is, pointing someone at the stacked borrows doc is usually met with a glazey stare, and while many things are discussed either here or in zulip, it can be difficult to find a concrete place to point (especially as "zulip conversation" is behind a login, and seems likely to be especially unconvincing, as message-board threads tend to be)

I'm not sure about the precise invariants around references. I agree it does make sense to compare that sort of thing — it proabbly is worth calling out that Rust references do require alignment regardless of whether C++'s do as well, as whatever the answer is, it seems likely that a subset of people believe the wrong thing about it.

[RalfJung]

Sure, but I think it might be better for the purposes of education to separate and explicitly mention some of the different consequences of stacked borrows.

Oh, I fully agree, I just want to be sure we also have the actual underlying reasons for these things documented. :)

it proabbly is worth calling out that Rust references do require alignment regardless of whether C++'s do as well, as whatever the answer is, it seems likely that a subset of people believe the wrong thing about it.

I'd probably generalize this to the entire concept of initialization invariants.

enum, btw, is another case where Rust has more UB than C (in C, enum are basically integers). This is the case even for #[repr(C)] enums.

[bjorn3]

(especially as "zulip conversation" is behind a login, and seems likely to be especially unconvincing, as message-board threads tend to be)

There is a zulip archive that doesn't need a login: https://zulip-archive.rust-lang.org/