as someone who's pretty much only written high level languages and doesn't really know what they're talking about, doesn't memory safety generally refer to referencing data you shouldn't (things like buffer overruns?)
> what is "safe" code without a guarantee of memory safety?
Memory safety is the absolute minimum for safety critical code.
It seems to be surprise for most people that you can write memory safe code in C and check for that statically and that includes static stack and heap exhaustion checks.
Uh, most? Memory safety is about data races and concurrent access violations. De-referencing a nil pointer isn't a memory safety violation, for example. But I guess if you re-define memory safety to mean anything that can produce a segfault then sure.
> A JIT is not, by itself, unsafe. The problem is that maintaining the complex set of constraints and invariants necessary to generate both safe and performant code is extremely difficult, and one slip-up can mean generating code that breaks some invariant and escapes a safety boundary.
I mean… isn't that what unsafe means? A "memory-unsafe" language means a language it's possible to make a mistake in, not one where memory errors happen all the time.
> I read the paper's description, and still don't quite understand exactly what they mean by "memory safety". This is not referring to safer programming practices like using the STL with iterators, correct?
I would assume it's referring to some kind of actual guarantee, which STL doesn't provide even in idiomatic use, due to things like iterator invalidation or subtly broken use of references.
I don't think you understand what memory safety means. Please look it up.
It's independent of how you write or design your program. It's a property of the language + runtime combination.
(Folks out there downvoting me: you could do with some education too... Parent is a completely ignorant (in the best possible sense - easily fixed) comment.)
please correct me if i'm wrong :)
reply