pub enum Subobject {
Off,
Members,
}Expand description
Whether an access has to stay inside the member it names, from -fsafety-subobject.
Design: spec/safe-memory/09-type-init-and-races.md section 9.4, which is row S4 of document
03 and is the class Fil-C, CHERI by default and ARM MTE all miss. Their metadata is per
allocation and a member is not an allocation, so an overflow from one member of a structure
into the next is invisible to all three. The type plane is byte granular, so it is not
invisible here.
A flag rather than a default because of what a store means. C 6.5 says a store to allocated storage sets that storage’s effective type, so a write that leaves one member and lands in the next is, read literally, a program retyping bytes it owns. Every buffer that gets reused for a second kind of value does the same thing on purpose. So the question a store asks is only asked when somebody has said they want it asked, and what they get in return is the write half of S4 that nothing else catches.
The read half is not behind this and never was: a read that disagrees with the plane is judgement J1 at every tier, because reading bytes back through a type they were not stored through is undefined however the pointer got there.
Variants§
Off
No -fsafety-subobject. A store records what it wrote and is asked nothing.
Members
-fsafety-subobject. A store asks the plane whether the bytes it is about to write agree
with the type it writes them through, which catches an overflow out of a member into a
member of a different type.
Two adjacent members of the same type are indistinguishable to this, which section 9.4
states plainly: struct { int a; int b; } overflowing from a into b writes int over
int and there is nothing for the plane to disagree with. That is what
-fsafety-subobject=strict is for and it is not here yet.