The defined behavior can be trapping, which makes more sense in 2019 with software safety / security / robustness as such important issues. Hardware can and is being designed to make it efficient to catch these issues too. It can also just permit safety without using 'undefined'.
Conversation
That definition would make lots of real systems stop working, so that’s clearly the wrong direction for the spec. A good spec respects its customers.
1
2
This Tweet was deleted by the Tweet author. Learn more
It does exist. Existing hardware has lots of safety features in hardware that are being actively used to catch these kinds of issues. More of those features are shipping over time. Intel CET and ARM MTE (which is like the existing SPARC ADI) are major examples of new features.
1
1
There is nothing about Intel CET that requires UB from the language; as I said, the compiler/spec don't have to reveal how function calls work. In my C spec, a load/store would be said to either load/store or trap, depending on how the runtime/CPU did things. So ARM MTE is OK.
1
So, it's okay to trap when indexing from one object to another and then dereferencing, or when constructing a non-derived pointer to an object in any other way and dereferencing it? That's what memory tagging will cause, since it aims to have the tags not match in those cases.
2
For example, the baseline for malloc is to set random tags for each allocation, along with adjusting them to avoid matching values for adjacent allocations. The compiler can do the same for stack frames (or even variables). Only properly derived pointers will actually work.
1
And you say it's OK because you're fine with invalid loads / stores trapping but then you clarify that you aren't aren't OK with that because you want breaking memory safety to be permitted. The whole design/purpose of MTE is giving C an efficient approximation of memory safety.
1
I'm not contradicting myself. I'm not fine with "invalid" loads/stores trapping if "invalid" is defined by the spec in terms of objects. But the spec can say that trapping is a possibility. Then an environment can make some loads trap. That happens to neatly describe reality.
1
MTE is an implementation of the rules about only being able to use pointers to access and object that they're derived from. That's pretty much exactly what it implements. Every pointer must have a tag matching the memory being accessed. Derived pointers will have a matching tag.
I know what MTE is. What I'm proposing doesn't make MTE stop working. A spec that reflects the reality of how C programs execute can allow things like MTE to exist, because it would acknowledge that loads and stores are actions the CPU takes which can result in arbitrary effects.
1
Note that this doesn't mean disallowing motion of loads, or even allowing strict aliasing. It's possible to write a compiler that moves loads/stores so it's possible to write a spec that says that this is what the compiler can do.