On: Why Go?

[pjmlp]

- Make it easy to write buffer exploits

[lihaoyi → pjmlp]

- Off-by-one errors should be security vulnerabilities, rather than just crashes

[DennisP → lihaoyi]

Can't say I agree. You tend to find crashes pretty quickly. Security vulnerabilities tend to be found later in much more embarrassing ways.

[jff → DennisP]

I'm pretty sure he was joking, in the same spirit as the comment one level up.

[wslh → pjmlp]

And the software that protects from them.

[pjmlp → wslh]

A language that allows buffer exploits cannot by definition protect you from them, because the tooling is unsound.

[wslh → pjmlp]

Yes it can, the proof is the security software that is written to do that in C/C++. Nobody is saying that the protection will protect you over all possible buffer exploits.

[pjmlp → wslh]

There are no guarantees that the security software is not exploitable given the quicksand it is built on.

[wslh → pjmlp]

What's the difference to my comment? I didn't make any assertion about warranties.

[pjmlp → wslh]

From Computer Science point of view if you are writing bug verification tools in an unsafe language, there is no guarantee the verification tool is giving safe results back.

The same unsafe constructs can cause memory corruption in the verification tool and lead to a behavior where the wrong decisions are taken.

So the fact that many C verification tools are written in C itself does not proof anything about how safe the language could be.

For me personally C could be much better if:

- There was no automatic decay from arrays into pointers (call an explicit operation to do so, like &a[0])

- There was a proper string type available

- Arrays were bound checked (with optional disabling of bound checking, like many other languages offer)

[wslh → pjmlp]

I have studied computer science, thanks. You are arguing against something I never said.