Conversation

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"?

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.

Replying to

and

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)

Replying to

and

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?

Replying to

and

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!

Replying to

and

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.

11:22 PM · Sep 7, 2022Twitter Web App

Replying to

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.

Replying to

and

Agree data races can be memory safe - although even then again there's a question of accessing allocated-but-yet-deallocated memory, vs maintaining expected semantics. Java split-writing to longs comes to mind...

Replying to

and

Java libraries using FFI or low-level unsafe primitives are required to maintain memory safety in the presence of those races. It's not much different than the expectations for unsafe in Rust beyond Java accomplishing the memory safety goal in a different way allowing more races.

Show replies