Jack Ganssle’s C rant. Essential reading for any System Realization team. I mean it

I’ve mentioned Jack Ganssle many, many times before. In my opinion, he knows more about software quality, and how to get it than anyone else in the business that I know. He’s just written a picture-perfect characterization of C. It’s the best of languages and the worst of languages. Here’s the Ganssle rant on C, just published in his very helpful Embedded Muse newsletter:

C Sucks

C, the most popular of all embedded languages, is an utter disaster, a bizarre hodgepodge meant to give the programmer far too much control over the computer. The language is designed to provide infinite flexibility, to let the developer do anything that can be done on the computer.

Don’t get me wrong – I do like programming in C. Assembly is even more fun, which proves I’m some sort of computer gearhead, more fascinated with the system’s internals than with actually delivering products.

But no language should allow stupid mistakes like buffer overruns or undetected array overflows. When compute cycles were in short supply it was logical for a language to not check results, but those days are largely behind us.

Geodesic claims that 99% of all PC programs (most written in C and C++ of course) have memory leaks, all caused by poor use of malloc() and free(). Though these constructs are less common in the embedded world, an awful lot of firmware does use dynamic memory allocation.

The language should simply not permit leaks; checks to guarantee memory integrity are essential. The cost is minimal. (Check out mem.txt at snippets.org, a simple bit of code you can link into your embedded app to detect all sorts of malloc()-related problems.)

Pointers are utterly unbounded in C. Want to dereference a null pointer? Go ahead! The language cares not a whit. Feel free to do any sort of math to any pointer. It’s fun!

Here’s a C hint that will improve your job security: embrace double indirection. Even better, try triple. Real programmers use quadruple.

The only limit to the number of asterisks placed in front of a pointer is the size of one’s cojones or how adventurous you feel.

Exception handlers are totally optional in C. Sure, they’re nice to have, but the language itself does nothing force us to either write such handlers, or to write them in a way that’s likely to work.

Even something as simple as integer math produces unexpected results.

20,000 + 20,000 may be a negative number. Is this cool or what! Even better, the fundamental concept “int” has no meaning at all. It depends on the CPU, the compiler, and the wind direction.

C has no formatting rules. It’s easy and usual to write source in astonishingly cryptic ways. C is more an encryption tool than an aid to creating reliable and maintainable code.

No other language has an obfuscated code contest. Win by writing code that works but that’s so convoluted no C expert can understand why.

Most of the entries look like a two year old hit a few thousand random keys. And no, I’m not putting the URL of the contest here; these people are code terrorists who should be hunted down and shot.

A great programming language should encourage users to create perfect code. It must bound our options, limit our freedom, remove the degrees of freedom that lead to stupid bugs. Ada did this. It was so syntactically strict that the rule of thumb was “if you can make the damn thing compile at all it’ll probably work.” The language itself served as a straitjacket that led to reliable firmware. So of course Ada more or less failed, now barely appearing as a blip on language surveys.

C sucks. Sure it’s fun and efficient. Debugging is much more of a kick than taming an angry syntax checker that insists on correctness.

But it’s time for the entire firmware community to either embrace a restrictive dialect of the language, or to adopt an Ada-like lingo that implicitly leads to correct code.

But C is like COBOL – it’ll never go away. The best we can hope for is the use of standards, like MISRA, that constrain the language.

What do you think?

Note: You can read more of Jack’s mild opinions at www.ganssle.com. Be sure to subscribe to the Embedded Muse too!

About sleibson2

EDA360 Evangelist and Marketing Director at Cadence Design Systems (blog at https://eda360insider.wordpress.com/)
This entry was posted in EDA360, System Realization and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s