Safety

It’s usually a good idea to avoid programming language flames, but this one from last year is a bit amusing. It defines “freedom languages” (Ruby, Python, Perl, Smalltalk) and “safety languages” (C++, Java, C#, VB, Delphi, Haskell, Nice). At the end of the piece the author treats us to this astonishing revelation:

All other things being equal, I think I’ll choose freedom

Furthermore, “freedom” = boxers, “safety” = tighty whities (ok, not really).

The useful bit of information is that the author includes C++ on his list of “safety” languages. This points up a bit of a problem for Cyclone: there’s no accepted definition of “safety,” and, in fact, people use the word to describe unsafe languages.

I don’t think there’s a good fix for this; if I recall, Matthias Felleisen took a stab at a general definition of language safety, but I don’t know that it went anywhere, and I’m not aware of other work on the topic. And in the end, the general public will use the word as they want to, not the way we want them to.

I think that the best we can do is try to give examples of what we consider safe and unsafe. We should build a wiki page to collect this information. In the meantime, here’s one (perhaps) surprising example:

Q: if a program segfaults, is it safe?

My answer is, yes, that may be safe.

For example, imagine that you could magically transform every C program in the world so that in case of a buffer overflow, the program would immediately segfault. This would be great! It would mean that instead of being corrupted, programs would halt immediately if they were attacked. In other words, the system would have a fail-stop property.

Fail-stop would mean the difference between a corrupted, “zombie” program under the remote control of some attacker, and a dead program. Not ideal, but a great improvement. In fact, fail-stop is a crucial ingredient of one definition of safety.

The same argument can be applied in other cases. For example, there is no safety reason to check for NULL pointers, because a NULL pointer dereference on modern machines will cause a segfault. There may be other reasons (recovery from errors), but it isn’t a safety issue.

24 April 2006 by trevor #