My love-hate relationship with C -

My love-hate relationship with C

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. C++ isn't much better. The languages are 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.

Geodesic claims 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, 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 is (ta-da) a negative number . Is this cool or what!

C has no formatting rules. It's easy and usual to write source in astonishingly cryptic ways. Any language that allows utterly random use of the ENTER key (it's perfectly legit to hit ENTER after almost every character in 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 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 usage surveys.

Other options exist. The MISRA folks have a set of rules that limits use of dangerous C constructs. Cyclone is a sort of C dialect that leads to more correct code. Neither has much market presence.

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.

What do you think?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at . His website is .

Reader Feedback

I believe that it's more of a balancing act – that is,safe and correct coding. Where I work there is a great deal ofthought and effort going on to “get it right” and that is great. However, making the tools “fool proof” or “safe” is rather difficult to say the least. Ever ride in an aircraft? Consider the training of the pilots and crews in that “very dangerous” environment. Airbus set out to “make it safe” for the pilots. The tool killed a few of them. It's a tough call in general. I personally like freedom when designing and coding. But issues of safety are of the most important nature and preventing stupidity is important. The problem with preventing stupidity can come about when stupidity is trying to prevent stupidity. This happens quite a bit in organizations a nd we all think we're smart (right?). My best bet on keeping things upside right and safe is education and trainging. It has to be right or you're a goner by the way. Pilot experience speaking here. Wrong training produces imcompetance and disaster. As for the “tools” of the trade. Sure would be nice to be able to feed experience into the language/compiler so that the whole thing just doesn't become some sort of leagalistic bandaid. And those sorts of fixes tend to have REALLY heavy and immovable anchors. In aviation there is a rule that is quite interresting (especially coming from the FAA): In an emergency the pilot in command may break any or all of the rules in the interest of the best outcome for the pilot, passengers and crew. The pilot may be asked to provide some documentation regarding that decision by the way. The point is, the pilot is trained to deal with the tools and the processes (including querying ATC when they ask you to do something that is unsafe – happens). So, for now, I would rather be hard on the programmers/engineers and their training. Adjust the tools or tailor them. No straight jackets PLEASE…

– Scott Miller

I am totally blown away! For the first time someone has spoken the truth about C forwhat it is: A TOY FOR TINKERING WITH THE COMPUTER!

I have only programmed in (Embedded Visual)C(++) when it was necessary. I always viewed C as atoolbox with lots of tools, many of which had the same purpose but with a slight nuance. (NIHS). Ispent too much time figuring out the nuances instead of programming. What really soured me was atime sensative project when I increased the size of a string without increasing the size of thebuffer. The system just crashed with no indication of what was wrong. Took me all day to find it.I made a resolution right there to stick with Pascal. At least it would have truncated the stringand I could have spotted the trouble right away. This is especially true when you are makingchanges under the gun.

Thanks, Jack, for vidicating me in all those discussions with C GURUs.

Let the boys have their C toys. But as for me , a professional programmer, give me Ada or Pascalso I can get the job done in a timely manner and maintain the code for years to come.

– Frank Putnam, Jr.

Disliking C because it doesn't do enough to prevent errors is like disliking Englishbecause it allows you to say stupid things at parties or hurt your spouse's feelings. And by theway, having your java program try to limp along after yet another “Null pointer exception” hastrashed some key data structures isn't really doing your system any favors. Don't blame thelanguage. The problem is software development culture that isn't obsessed with objective riskassessment and mitigation. I've seen way too many coding standards docs for C, C++, Java,assembler, whatever, that focus on things that have nothing to do with real risks that need to beaddressed in the software's development, testing and operation.

– Presley Barker

At last ! Someone who sings from the same hymn sheet as me. I only ever use C ifthere is no viable alternative language available for the processor in question. My preference isfor Pascal / Delphi, alas not avialable on most microprocessors. Even so, when I use C, I try tokeep to Pascal style formatting and language constructs. C should have been strangled at birth,and certainly never released into the wild.

– Andy Syms

It gets lonely sometimes,programming in Ada that is. Its refreshing to see a 'c' freaklike yourself give Ada some credit. Thank you.

– William J. Thomas

What is going on with ADA 95? I talk to people who use it and they seem to like it. The GNAT freeware compiler supposedly works. I haven't seen an article on ADA for years! Haveyou come across projects/companies that use ADA outside the aerospace industry? Maybe ADA basedprojects don't require calling in outside help to save the day.

– James Munn

Thank you so much for that wonderfully accurate article “My Love-Hate relationship with C”.I was weaned on computers through the use of Pascal and its beautiful set of structured programming requirements, bounds and limits. Throughout my succeeding years I've been forced to use C occasionally and hated every minute of it. In the early 90's I worked for Raytheon and wrote programs in Ada. That was a pleasant joy. I wish those who thought that C is the 'only' programming language, would take off their blinders. I'm tired of trying to debug other people C-code.

– Russel Buckley

Well, I think this is the first time I've read one of yourcolumns and didn't totally agree with your point!While no one can deny that C allows you to shoot yourselfin the foot, does that mean it sucks? No way!

I built a deck in my backyard and used several very essentialtools, each of which, had I used them improperly I could havedone a lot of damage to myself. Does that mean those tools suck?

A police officer carries a gun, which he could potentially useto shoot his partner. Does that mean the gun sucks?

My wife goes to the grocery store and buys a few cans of soup.The soup can doesn't prevent her from throwing it at anothershopper does it? Does that mean the soup can sucks?

Millions of folk drive to work everyday, in vehicles that couldbe used as weapons. Does this mean that cars suck?

Just because something is designed in such a way that it impliesthat the user will take on some of the responsibility doesn't mean that the original design is bad. I don't disagree with any of your points regarding some of theimprovements that could be made on the language, but that doesn'tmean that the language, which has essentially created our industry,sucks!

I especially hate browsing source code and seeing a variety of different “styles”, or in many cases a total lack of style.This makes me crazy, but I admit that I probably do it sometimesmyself especially with older (pre-ANSI) source code that I'vemigrated into newer projects. I take responsibility for thatneeded cleanup, it's not C's fault!

Regarding other runtime checking, yea it's nice to say that weneed it now, but back in the days when the CPU frequencies wereunder 10Mhz, it was good to know that the only runtime checkingthat was done was what I put in the code.

Anyway, I just find it to be a bit harsh to say that “C sucks”.

As always…Fun stuff!

– Ed Sutter

I just finished reading with great interest your article “My love-haterelationship with C.” I share you amazement at the flexibility withoutbounds that this language offers. My first experience with C came whenI changed jobs in 1991, moving to an early networking company from adefense contractor where my last project had been coded in Ada.

The differences between Ada and C were staggering. With Ada, there wererules, lots of rules. And most of the rules were good rules. Let'sface it, we're all human, and we make mistakes. It's a lot cheaper tolet the compiler catch the mistakes early on rather than catching themduring code review, unit testing, integration, or beta testing. And Adamade you modularize your code, and made you publish clean APIs. And itallowed you to publish your APIs so that others could write code tothose APIs. And others could write their own stub implementations ofthe APIs to test their code. In the article you commented “if you canmake the damn thing compile it'll probably work.” That was myexperience. It took a lot longer to code in Ada, but the backend timefor testing and integration was significantly reduced. And it's notlike Ada didn't allow you to do real embedded code. After all, I waswriting device drivers and interrupt service routines that used both I/Oports and memory-mapped I/O, so I wasn't handcuffed from that point ofview. In fact, I'd say the only negative was that there were only ahandful of compiler manufactures, and the code that was produced was”bloated,” and as a result, ran slower than expected (compared againstan earlier, similar project coed in PL/M). But that wasn't a fault ofthe language per se, just a need for the support tools to mature.

When I started to code in C, I was definitely surprised at the lack oflimits on what one could do. Lack of array limits, pointerdereferencing and casting, assignments and arithmetic using mixed types,and functions without prototypes were just a few of the features/bugsthat were part of the proverbial rope that was available for me to hangmyself with. I remember looking at my first piece of code which I had tomodify, code which contained a function call via an array of structswhich had a function pointer field, and thinking C, like APL, sure lookslike a write-only language because it sure was hard to understand whatthe original coder was trying to do. And that's from someone who priorto coding in Ada was writing assembly language programs using theFairchild 9445 extended-Nova instruction set (ah, memories; nothing likean instruction set which allows you to shift, perform arithmetic, andbranch all in one instruction — but I digress).

I'm simply amazed at how difficult it is to write bug-free C, and howeasily the most sinister defects can creep into the code. But I guessthat for those of us who have a track record of delivering high qualitycode, an employment opportunity is always out there!

Thanks for you insightful articles!

– Jeff Johnson

I agree with you on all your comments, but you need some thing so powerful ( AsPowerful as Aseembly ) and allows you to create maintainable code, C has both the things, Linuxdemostrate this as entire OS runs but developed by different programmers across the world,It is simple to to use or even shoot your self, just take care of your self! you are the bestperson to do that than some thing else!!!!!

– Anne Ajaya

Stop whining! If you like C, learn to write good code, and/or build around the primitives that itprovides. If you don't want to do that, then you might as well have someone else do yourprogramming for you, 'cause you're never gonna be satisfied.

If you don't like C, use something else.

-Rohit Patil.

If I could get ADA code to run on a Z8 or AVR I'd love to use it.

Cyclone is hampered by the bazaar licensing of AT&T (who every they might betoday) [Might have changed licensing by now I hope].

I'm going for Esterel myself, it will run on the AVR, and will know if runs on the Z8 shortly.If you can do a Airbus plane with it, you should be able to do most embedded projects with it.

A open source version of Esterel is being worked on.

Check out the mess they made of the 'safe' language R++ under Software Patentsat .

– Bob Paddock

Jack, I don't often agree with what you say, but on this point I agree completely. Ilove 'C', but complex systems (systems over 100K lines) should not be written in this language(except by the absolute creme of implementors, led by the creme of designers). Ada would be best,but as you state not practical due to the lack of popularity.

Java is the only commercially viable choice for something with at least 'C's more glaringdeficiencies eliminated.

Describing a compiler with strong checking as a straight jacket is inappropriate (as it impliesthat it reduces your ability to function); an engineered programming language is more like aVolvo; it doesn't impinge on the effectiveness of function – it get's you anywhere you want to go- but Mario Andretti would probably choose to drive something a little less safe (and he couldpull it off without any problem).

Most programmers know this, the only problem is everyone thinks they are Mario Andretti (just like80% of Americans think they have an above average income).

– Rennie Allen

Although I agree with your disposition on C, Ada (83) never promised ordelivered implicitly correct code. There were fun ways to abuse it, such asUNCHECKED_CONVERSION. And the standard's lack of built-in string handlingfunctions and a decent math library were simply unacceptable. The strongpoints of Ada were the strict language syntax, the implicit “make” that wasnecessitated by this strictness, and its few object-oriented features. Therendezvous concept was incomplete and most often a 3rd-party RTOS had to beused.

The language certainly was a step in the right direction, though. For awhile, I preferred coding in no other language. I used Ada from the get-go.My first Ada application in 1986 ran on an Intel 80186 and utilized whatshould have been Softech's ALS (Ada Language System) for the U.S. Army.What ultimately killed Ada was not necessarily its lack of acceptance bythe programming community at-large, but rather by its lateness to market. Imean, it seemed like a good idea. That is, the Govvie driving the standardand making it so strict that you couldn't even call it an “Ada compiler”unless it passed a rigorous battery of validation tests. The language wasflawed, and compiler vendors found them all. The Army ultimately abandonedthe ALS contract with Softech because it just kept dragging on and on,always late and over budget. What we used was an unfinished product thatproduced very buggy code.

Sure, in time there were decent Ada compilers. I can recall a few: VAX Ada3.0 (my fave), Meridian, and the one I used the most, Tartan. The VAXcompiler was my favorite because of its “smart recompile” feature. Itactually determined if what had changed in a package was actuallyreferenced by others dependent on it and did not recompile the dependentpackages if there was no need. The Tartan compilers, which I used forMIL-STD-1750A and TI DSP development, were okay but we opted for VRTX orsome other 3rd-party RTOS over the rendezvous. The arrival of goodcompilers and development systems simply came too late, and the defenseprograms committed to using it pressed on and dealt with the pain.

Ultimately, the Govt. attempted to both cleanse the language and move itfully into the Object-Oriented world with Ada95. Besides being a tremendousimprovement to the language, this meant an even more complex underbelly(run-time system) and pointed out some of the flaws in Ada83. In essence,the introduction of Ada95 was an admission that Ada83 contained flaws,which seemed to overshadow its new features. It wasn't enough that thetarget was so hard to hit the first time around, now there were even morerules. The reaction to the release of the Ada95 standard was underwhelming.

The final blow to Ada was the lifting of the Govt. mandate for the DoD andother Govt. agencies to use the language. I am sure what caused the massexodus off the bandwagon was the relief that defense programs would nolonger have to fund the development of the language or suffer delaysbecause of problems with development tools. In a nutshell, time and moneydid it in. And although the trend of producing somewhat bug-laden softwareproducts prevailed, at least they were being delivered on time and withinbudget again.

I think if the professional standards community had authored MIL-STD-1815A(not by that title, of course) and the commercial industry had been thepush behind it, taking away the strict requirement for validation beforeuse on a defense program, Ada may very well have been alive and prevalentin the U.S. software market today. And I don't mean just the defenseindustry. I'd love to see it come back into vogue. Certainly, the Europeanshave embraced it, particularly in their space industry(

It is possible and quite easy to write good C and C++ code. I do it all thetime. But we have to rely on company policies, standards, and processes toensure it. Discipline has always been a facet of engineering, and C demandsit. Companies that let their programmers and software engineers write lousycode are likely spending too much money on software development,particularly rework. But that's their choice (or ignorance).

Ada was the greatest embedded systems language ever conceived. I miss it.

– Bruce Scherzinger

Just read you article and I couldn't agree more.I'm a hardware designer who also happens to really enjoy programming what I design and I like Calso but I'm toying with the idea of using Ada next time I have to write embedded diagnostic codefor hardware bringup and test.

Ada was designed from the ground up as a language for software **engineering** rather thanhacking; maybe that's why Ada is far less popular. Ada certainly has a steeper learning curve anddevelopment tools are a little harder to find.

By the way, I like VHDL versus verilog for a similar reason: VHDL is a hardware engineeringlanguage. VHDL is to Ada as verilog is to C.

– Keith Outwater

For those wanting to find out about the current state of play in the Ada world, here are a coupleof sites: & – general interest sites; – you can download the public version of the GNAT compiler from here; – a simple, free IDE for the GNAT compiler; – the 'official' Ada home :-);
comp.lang.ada – still up and chatting!

To the person going to use a Z8 or AVR, check if there is a 'gcc' compiler for them. If there isthen GNAT is a potential Ada compiler.

For the person wondering who is using Ada outside the military here are a couple of the 'cooler'examples:

1. Philips remotely control, from Holland, their Far-Eastern chip fabrication using plants Ada;
2. Check out the Beagle 2 Mars probe – it's pretty much all Ada;
3. If you have digital TV in Europe, there's a fair chance it is transmitted using Ada.

– Martin Dowie

Was this article written because this was an assignment – “to write an article trashing'C' Programming Language”?

Almost all of the issues raised in this article are the issues of the lack of discipline on partof the programmer, lack of coding guidelines, lack of coding / programming standards etc.

Any Programming language is just like any other tool. It enables us engineers to implement thedesign. It may not be appropriate to blame the tool for errors that are Human in nature. Anyprogramming language, like all the tools, is only as good or as bad as the people using that tool.We may make a case for tool improvement but should not “hate” the tool.

We should appreciate the fact that 'C' allows the Programmer to be free and be creative. Thisdoes not give the programmer a license to make mistakes and then blame the tool.

Response by Ed Sutter said it the best, I fully agree with his views. Good response Ed.

– Vivek Jain

I'm presently working on two projects: one is firmware for a low-end 16-bit microcontroller in C,the other is for a Windows 2000 target using Visual Studio .NET. This is my first .NET project,and I find the environment with its strict syntax checking and automatic formatting to be, as yousay: “restrictive”, but I also find it to be almost Ada-like in that by the time I get it tocompile, it usually also works! (.NET takes this one step further in that the syntax checking isgoing on while you type. If you can get rid of all the little squiggly underlines while you type,it'll usually compile!)

However, I also find the .NET environment to be very helpful in offering context-sensitive helpand popping up lists of syntactically correct choices at any given point in one's typing. It'salmost like having that second programmer looking over your shoulder in XP's “pair” programming.

.NET has this thing called managed code with automatic garbage collection which watches out foryour array accesses and freed objects and so forth. I can be a lot lazier because the environmentdoes so much of the work for me! The only problem is most embedded systems can't afford theburden of this overhead.

Nevertheless, I feel there is a lot more that could be done at the level of the developmentenvironment where the power *is* available, without imposing much if any burden on the target.What if the manufacturers of these lint tools and memory-leak detectors and compilers for smalltarget MCUs got together and integrated these tools into a .NET-like IDE that watched over you asyou typed and helped “restrict” you to good programming practice? Might as well put that 2GHz CPUwith 512MB RAM and 80GB hard drive to good use rather than idle for a few hundred million cycleswaiting for your next keystroke!

– Brad Peeters

C++ is the light-sabre of programming languages. If you don't know what you are doing,you will cut off your own arms and legs. This inherent danger isn't sufficent reason to keep thepowerful tools out of the hands of the masters.

– Bob Wise

As a professional software engineer, I think that Mr. Ganssle's rant is a bit immature and I pitythe folks that take his seminars on embedded code. If he wants to not take responsibility foranything he does in code then he should go work for the Microsoft virus-writers. Limiting C'suseful features–such as no bounds checking on arrays, and being able to dereference anypointer–are useful mechamisms. His whiny complaints are akin to wanting to take away all carsbecause some moronic drunk might attempt to drive one. Not all tools are made for the same job:want to slap together a simple GUI? Use VB. Need an application to run across many platforms? UseJava. Need to get down to the silicone and actually make a computer dance? Use assembly. Thatcan eat many man hours though, the next best thing is C (or a mix of C and assembly). The righttool for the right job. I have used some of the feautres he complains about in firmware I havewritten. Sure, pass a function a pointer to a chunk of memory and the function can overlay anystruct it wants. It's called information hiding. People rave about C++, but the truth is,anything that can be one in C++ can be done just as well in C.

– Troy McVay

Jack's response: ICs are made of silicon; silicone is used for breast implants…

Jack, if you think C is bad, you obviously have never seen perl. Perl does indeed have anobfuscation contest, and it is much worse than the C obfuscation contests ever where!

As the saying goes, perl gives you enough rope to shoot yourself in the foot….

– Buddy Smith

Jack's response: Buddy, good point. I do use Perl on occasion. And it is indeedworse than C. I usually use Perl when I have only a vague idea how to get something done,and I'm fiddling with regex's and all. Hacking.

Oh boy, I hope your mailbox is big enough. I am sure you will get tons ofmail on this subject. The only topic that might bring in even more mailwould be “C vs. Assembly Language”, which this topic could easily turn intoafter some discussions 🙂

I also have a love-hate relationship with C: I hate the way it “lets” memake mistakes, but I love its efficiency – it writes code in assemblylanguage just about like I would do it. I really cannot fault a compilerfor “letting” me make mistakes. If I am in good control of my code, thereshould not be any mistakes. I should design it properly such that itdoesn't do all the horrible things we hear about with C. Having said that,it would be nice to have a more strict C to keep me in check, as long as itdid not sacrifice efficiency, and still promoted readability.

To help with code development, I like to use Lint. It cannot catch somerun-time problems like array bounds or wild pointers, but it does help withthe more mundane things like “if” constructs. It REALLY bugs me when Clets me write “if (a = 5)” when I really meant to write “if (a == 5)”. Itbugs me because logically the statement is always true, and any goodcompiler should at least issue a warning. I always say Lint is a supercompiler that doesn't produce any code. It can be the most annoying thingyou have ever seen, or can be your best tool, depending on how it isallowed to run.

Maybe the problem with C is in its origin. The original writers of Unixmay have liked it because they could more quickly code an operating system. Who cared about some strange things it let you get away with – it was aheck of a lot faster than assembly language. And I would add (see heregoes the C vs. Assembly Language things again) that C definitely makes iteasier to code with less things to worry about and get into trouble withthan assembly language. Whatever horrible things you can get away with inC, are even easier to get away with in assembly language. But maybe forall the applications C is used for today, it really should be more strict,not letting the programmer get away with so many terrible practices.

So I would have to conclude that I like C, but would like to see itrefined, as long as the improvements were not at the expense of codereadability, code size, or execution speed. Well, you asked for it.Thanks for the article Jack.

– Lou Calkins

It may interest your readers to note that while some checks that Adaincludes have to be done at runtime, loads of them can be made at compile time andthe intent is that for Ada0Y, more will move from runtime to compile time, ascompiler techiques improve.

The result? Fast, small code.

There aren't the same Ada83-style-bloatware compilers out there anymore. Ada95compilers produce excellent code quality, comparible to any other efficient language.

The people at ACT (who sell/maintain GNAT) have examples of how Ada programs canproduce *identitical* ob

6 thoughts on “My love-hate relationship with C

  1. It continues to dismay me that so many programmers respond to the serious flaws of C and C++ with what is essentially a “man-up, sissy!” attitude. Too much of our industry does not take flawed software and flawed tools seriously. Flawed software and flaw

    Log in to Reply
  2. I view C as essentially a structured, somewhat portable assembly language. For the sorts of things I would otherwise do in assembly language, C has become a fine tool. I'm talking bootloaders, working with the hardware, little microcontrollers, and the l

    Log in to Reply
  3. In my opinion about programming in C is that it has nothing wrong with the language itself. The fault lies in the documentation of how to use the C directives and keywords effectively. Most C programmers learn effective programming thru TRY and ERRORS and

    Log in to Reply
  4. I've never found any difficulty writing anything I can write in C in Pascal instead – but Pascal forces me to make my intention explicit from the start, and express it unambiguously, and then the compiler has a much simpler task and can produce *better, si

    Log in to Reply
  5. “The functions malloc() and free() are often misused. Regardless, said functions are dependent upon the library implementation and the consequences are not a language concern. I disagree that the language should “simply not permit leaks”. How would this

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.