Lambda the Ultimate

Coding standards such as this certainly do not guarantee that secure code is produced. No one involved in the creation of such standards would claim that.

The point is just to make things better. Ideally, we would have means to produce secure code under all circumstances. If this ideal cannot be realistically achieved, it is better to adhere to a coding standard that tells you how some mistakes are avoided rather than just to continue.

It is a bit like a road-sign warning you of a sharp turn... It doesn't automatically make you go slower and it doesn't help a bit if you ignore it. In many cases however it is actually very helpful.

There are legal contexts in which failure to follow "industry-standard best practices" can foreclose certain possible actions or even result in sanction. For instance, I would expect something like this standard to be validated by the due-diligence teams of anyone thinking of buying a software-intensive company. Going forward, I could easily see failure to follow practices like these used as evidence in product liability cases relating to insecure software.

If that's what Computer Science and Security boil down to in the industry, it's quite saddening.

that sort of thing will be the first sign that industry takes computer science, security, or software quality seriously. It's too much to hope that anyone outside our circles be actually excited by those subjects, but willingness to stake money on it will be a minimal sign that the general public considers such things actually worth caring about. As of yet, they mostly don't. That's sad.

Shouldn't "industry best practice" be to use different languages?

Out of interest, if you were starting with a legacy-free clean slate, which language(s) would you use to implement, say, a desktop OS kernel or a replacement for Apache? I know there are a lot of research/toy OSes out there that are implemented in not-C, but I am ignorant about industrial-strength, high performance stuff so would love some pointers.

Well, everybody expects me to say Ada, so I will...

Of course there are many other factors that need to be taken into consideration before making a decision, but using C these days (and even C++) seems to me to require very compelling reasons.

I will second Ada, and raise you SAFECode, if you like pure C, and Cyclone, if you don't mind a C dialect with strong typing and safe manual memory management. These are the most promising low-level language alternatives I'm aware of. I'm not aware of any low-level non-C dialect, but it's something I'd really like to see.

[Edit: I should mention that SAFECode and Cyclone are probably even safer than Ada and Pascal, so while they are both low-level non-C languages, they are not quite in the safety league of the C-dialects.]

I'm currently only using C for a minimal language runtime because it's simple and portable, and even then, I'm actively pursuing alternatives for anything beyond the JIT based on GNU Lightning. Ada looks the most promising if you want wide platform support. I just can't muster any excitement to learn C++. Just seems like a lot of effort, for very little gain.

One other point: The original question assumes that C is being used only for low-level systems programming. Is this true in general? Is no application development being done in C/C++ ?

Shrinkwrapped game programming is still largely done in C++, while enterprise coding has moved almost entirely away from in C/C++ in the last decade.

To Java...

The predominant use of Java in the industry in my opinion is pretty much self-sustaining by now. The wide availability of tools and mature libraries with adequate documentation all do their part of ensuring that people can produce something that works rather fast. Most people will learn Java because most Job offers are for Java developers and so on...

I feel, that in most cases the added effort of not going with the mainstream will simply not be paid for by the benefits that are expected from using something outside the mainstream. There are of of course cases, where the benefits actually do pay the cost of not going mainstream and - I guess that is when ADA is used instead...

The reason I mentioned Java is that it is easy to fall into the trap of asking about languages other than C that are appropriate for systems programming (a perfectly legitimate questions), when the question that is often more relevant is about languages other than Java, i.e., the "close to the metal" requirements are not relevant. Java is safer the C, so as far as this thread goes it is a better alternative. But since it is butt ugly, looking for alternatives to Java is also a good idea...

A great deal of general shrink-wrap applications work is done in C++. Such shops often skip the likes of Java and C# due to concerns about efficiency and onerous installation requirements. But how often do such shops even consider alternatives?

In fact, this is an issue I am trying to work out... Can we quantify aspects of programming environments in a useful way? Assuming that Java is 'ugly' and (for example) Haskell is not... When you compare both environments you can make a lot of qualitative observations, concerning the available mechanisms of expression and abstraction, type safety and so forth. You can further look at the available tools, the quality of documentation, the maturity of available libraries, coding standards etc. You might also consider the job marked and the likelihood of being able to hire a capable programmer that can get the job done in any of those environments.
Haskell and other alternatives win hands down for the first few points (expressiveness and abstraction), but when the other points are considered the mainstream (Java) catches up.
So while the mainstream is ugly, its also pragmatic. Hence in order to evangelize alternatives one might want to focus on underlining or enhancing their practical applicability rather than showing how they are less ugly then the most popular choice.

Hi Lars,
All these issues were discussed here ad infinitum. I never use my opinion that some language is "ugly" as an argument. It is a personal observation, nothing more. My point was only that while safety (the subject of this thread) is important, other factors - such as elegance - should also be considered.

I think it's fair to say that it is to JVM bytecode. J2EE EAR packages don't generally contain Java source.

And we've seen that the JVM supports quite interesting languages...

I asked it that way because I implicitly agreed that there is not a lot of reason to use C for application programming, even though there are plenty of people out there who do so still for various reasons (performance, masochism, ignorance, who knows what else).

I'd build my own language, but barring that, Oberon and its descendants have been successfully used to do just what you suggest.

Might this coding standard make it easier to audit conforming code?