Is there a formal definition for what it means for a language to be spatially memory-safe but not temporally memory-safe? Is it something like "memory-safe under the assumption that, once freed, that memory block (whether heap or stack) will never be reused"?
Conversation
Replying to
I don't really see how you can have one without the other. If you reduce the size of a dynamic array from 2M to 1M in-place and then access beyond 1M due to lack of temporal safety that looks a lot like an out-of-bounds access to me. They're not really cleanly separated things.
3
3
Hmm. spatial safety: all accesses are to memory that has been allocated?
temporal safety: no accesses to memory that has been deallocated?
C - neither
Java - both (excluding the evil low-level API)
2
boost::variant<int, double, std::string>
Type stored inside changes. Outer object lives, memory still there, but references to inside are invalidated.
std::shared_ptr<std::vector<int>> is shared between 2 threads. Both of them are appending at the same time. Which kind is that?
2
1
but really I'd prefer to say that the second case is a question of "thread safety" *not* "memory safety" -
assuming the point of all this is to come up with fine but meaningful definitions
what does say? He'd know!
2
Thread safety and memory safety aren't distinct that way. Data races can be perfectly memory safe. See Java. Java doesn't prevent data races at all, but it still enforces memory safety in their presence since it does keep the behavior of those races well defined.
2
If a language has the possibility of memory corruption through data races, such as in Go, then it's not a memory safe language. Java isn't really 'thread safe' overall language but it is type/memory safe even in the presence of those races. They can't break the type/memory model.