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?
boost::variant - I viscerally hate incoming pointers - arguably the problem is the "references to the inside" *aren't* invalidated. Seems similar to pascal variants: temporal not spatial?
std::shared_ptr - don't know recent C++. if they empty the pointer, spatial not temporal?
1
std::shared_ptr is an atomically referenced counted pointer managing the lifetime of what's inside. I was using it as an example of safely sharing a reference across threads and then having a data race on what's inside: appending to a dynamic array with no locking.
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
can you be memory safe but not thread safe?
clearly.
can you be thread safe but not memory safe?
I think so but it's a bit weird.
perhaps a coöperative threading system, but with manual memory management only?
1
Show replies