Hacker News Reader

Comment by pjmlp | Hacker News Reader

Don't bother, they haven't learned about writing secure code since Extended Algol (1961), Mesa (early 70's), Modula-2 (1978), Cedar (early 80's), Ada (1983), Oberon (1991),... anyway.

View on HN

17 years ago it was "Let's rewrite Unix in Perl" ... http://news.slashdot.org/story/99/02/28/1639216/unix-in-perl

I do wish them the best luck, though.

Strange to go back in time.

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.

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

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.

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.

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.

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

Almost all of these are solvable without the added abstraction, code size increase that most languages bring, see dependent types.

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.

Reply on news.ycombinator.com