The rust-reference implies that 64-bit types are aligned to 32-bit for
platforms with 32-bit addresses. This is not necessarily correct. Fix
the wording.
Note that there is no general rule how data-types greater than the
native address size are aligned. On most Unix'y systems, they use the
native alignment of the platform. However, the Windows ABI aligns them
to their size (up to at least 64-bit).
There are advantages for either of those decisions. But we should at
least make clear that there is no fixed rule for 32-bit platforms.
Signed-off-by: David Rheinsberg <david@readahead.eu>
This is part of the feedback on rust-lang/reference#1385.
Ralf made the point that the immutability definition could be restated
solely in terms of bytes, which has the added benefit of no longer
requiring the note on padding (since it's a natural consequence of the
byte version.)
The new wording for shared references also clarifies the case of mutable
references behind shared ones, and reintroduces some of the transitivity
property that I removed in my previous commit. The wording is separate
from that for immutable bindings, since those don't have transitive
immutability.
This also bumps the definition of bytes pointed to by references and
pointers into its own subsection, so that it can be linked to by the UB
definition, to avoid duplication.
Co-authored-by: Ralf Jung <post@ralfj.de>
I personally found this description of UB confusing, since the use of
"reached" suggests that UB only happens for read bytes, and the
definition of immutability is not given, allowing for multiple
interpretations: does the "data" have to be immutable from the first
read? From the creation of the reference? Between reads from the
immutable accessor, but not otherwise? etc.
This clarifies the actual UB conditions, based on this Zulip
interaction:
https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/What.20exactly.20are.20.22immutable.22.20and.20.22reached.22.20in.20shared.20ref.20UB.3F
and this reference discussion:
https://github.com/rust-lang/reference/issues/1227
in two ways:
* The definition of "data" is clarified to be stated in terms of
bytes, in a way that should avoid ambiguity about which bytes are
considered. Based on the GH issue, this clarification should also
allow for use of a `*mut` pointer through a shared reference, which
is not in itself UB. Based on the Zulip issue, the definition
includes padding bytes, which may be surprising.
* The definition of immutability & mutation for a set of bytes is
clarified to mean forbidding *all* non-0-byte writes.
David Rheinsberg
Joshua Liebow-Feeser
Eric Huss
lcnr
Isaac van Bakel
Matthew Woodcraft
Greg Schmit
Gregory N. Schmit
macaujack
hehaoqian
Tshepang Mbambo
Lokathor
William Sørensen
Kane York
Andrius Pukšta
Martijn Gribnau