5 ms·

Aren't Cedar and Oberon are the only languages in that list that are memory-safe (assuming no use of unsafe code)? They both achieved that distinction by adding

Aren't Cedar and Oberon are the only languages in that list that are memory-safe (assuming no use of unsafe code)? They both achieved that distinction by adding a garbage collector, so you could generalize and say that nobody has learned about writing secure code since Lisp in 1958. Also, I'm pretty sure that Oberon was quite a bit earlier than that.

pcwalton 11y ago
To be fair, the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure", which at least Ada does (Storage_Error).
- viraptor 11y ago
  Isn't it in practice a "this code wouldn't exist in the first place" situation? (I mean in context of Rust and many others) Either you'd have to go into unsafe{} block, of the buffer would simply be a Vec<>, which oom()'s on allocation issue. I mean theoretically the issue still exists, because you can run allocation yourself and get back null. But without unsafe this shouldn't be possible.
  - steveklabnik 11y ago
    Rust-the-language does not understand allocation, so it depends on the API that you give to whichever allocation functions. Rust's standard library aborts on OOM.
    - viraptor 11y ago
      That's what I meant - if you go through actual allocators, then of course such bug can exist. As you say <<the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure">>. But it seems to me like any language providing resizable buffers with bound checking in standard library is unlikely to get code like this in the first place. And that's a massive scope reduction.
pjmlp 11y ago
Yes, but the other ones already prevented: - implicit type conversions errors - memory allocations with incorrect size - implicit decay of arrays into pointers - lack of bounds checking for arrays - null terminated strings with missing null character - invalid pointers passed as argument for out parameters - implicit conversion of integers into invalid enumeration values
- nwmcsween 11y ago
  Almost all of these are solvable without the added abstraction, code size increase that most languages bring, see dependent types.
  - pjmlp 11y ago
    Dependent types are great, but I fear not for the average programmer on the street, at least not on the current languages that make use of it.

pcwalton 11y ago

To be fair, the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure", which at least Ada does (Storage_Error).

viraptor 11y ago
Isn't it in practice a "this code wouldn't exist in the first place" situation? (I mean in context of Rust and many others) Either you'd have to go into unsafe{} block, of the buffer would simply be a Vec<>, which oom()'s on allocation issue. I mean theoretically the issue still exists, because you can run allocation yourself and get back null. But without unsafe this shouldn't be possible.
- steveklabnik 11y ago
  Rust-the-language does not understand allocation, so it depends on the API that you give to whichever allocation functions. Rust's standard library aborts on OOM.
  - viraptor 11y ago
    That's what I meant - if you go through actual allocators, then of course such bug can exist. As you say <<the needed feature to mitigate this specific vulnerability is "throws exception on malloc failure">>. But it seems to me like any language providing resizable buffers with bound checking in standard library is unlikely to get code like this in the first place. And that's a massive scope reduction.

pjmlp 11y ago

Yes, but the other ones already prevented: - implicit type conversions errors - memory allocations with incorrect size - implicit decay of arrays into pointers - lack of bounds checking for arrays - null terminated strings with missing null character - invalid pointers passed as argument for out parameters - implicit conversion of integers into invalid enumeration values

nwmcsween 11y ago
Almost all of these are solvable without the added abstraction, code size increase that most languages bring, see dependent types.
- pjmlp 11y ago
  Dependent types are great, but I fear not for the average programmer on the street, at least not on the current languages that make use of it.