Embedded systems programmers worldwide earn failing grades in C

1/13/2010 12:15 PM EST

What's even more troubling about the results is that the engineers who took the test are somewhat of a self-selecting group. In other words, I would guess that engineers who visit the embedded.com & netrino.com sites, and make the effort to take the quiz, probably take their profession pretty seriously.

Can you imagine the results if *every* embedded engineer took the test? (shudder)

1/14/2010 2:25 AM EST

As an embedded programmer of 30+ years experience this survey does not surprise me that much. I would be curious to know if the survey asked about the educational backgrounds of the various firmware engineers. Were they trained as SW engineers that then came to the embedded world? Were they trained as HW engineers that came to the embedded world or finally were they systems engineers that were trained in both disciplines? Might be interesting to know and it might shed some light on this problem!

1/14/2010 2:51 AM EST

Yes it is sad indeed. Just look at the author of this test:

char *a = new char[20]; delete a;
char a = new char[20]; delete a;
char *a = new char(20); delete [] a;
char *a = new char(20); delete a;

Neither is the correct way to allocate and delete an array dynamically. The correct answer is

char *a = new char[20]; delete [] a;


:)

1/14/2010 2:52 AM EST

...And this site fails miserably at displaying code...

1/14/2010 3:45 AM EST

See this link for the correct way to delete dynamic arrays:

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.12

1/14/2010 4:00 AM EST

I have to admit that some of the variable declarations in the test made my brain hurt. As a principle, if it makes my brain hurt then it probably means that the code is not so easily readable by someone else - transgressing one of the tenants of software engineering.

1/14/2010 8:51 AM EST

Lundin,
char *a = new char(20); delete a;
isn't meant to allocate an array. It allocates a single byte, initializes it with 20.

1/14/2010 8:54 AM EST

Measuring C proficiency with a 10 question test, and specifically this test, is somewhat questionable.
One of the "right" answers can be challenged, and 3 others refer to declarations that should rather be avoided in professional code.

1/14/2010 10:08 AM EST

Perhaps this says more about C's (un)suitability as a programming language. The author seems to think the problem is poor programmers; how about a language that contains incomprehensible declarations and constructs (pointers) that virtually guarantee runtime errors? Hint: look at Java.

1/14/2010 10:38 AM EST

I admit that I should have had the right answers for two of the questions, especially since I used one of the constructs in some of my programs. However, two other questions are arbitrary:
1) "A variable declared static outside the body of a function can only be accessed by functions within the same module." Replace the word "module" with "function" and that statement is true. In my interpretation, a module is the C file in which the function is located which made the statement false in my mind.
2) "Which ANSI C compilers allow a variable to be declared both volatile and const?" What am I a C compiler or a programmer? I use the const construct primarily when I want to locate a table in ROM and I don't want the compiler to copy the contents to RAM on startup; I also use it with the reserve word "code". I don't waste ROM space for a single const variable; I do that with #define. I use volatile to describe a variable or register that may change outside of the function it is currently being use in. Since those two uses are as far apart as possible, why would I ever want to declare a variable as a "volatile const"? I suppose if I were bank switching ROM code the construct might seem valid but I don't even know how the compile write that code, let alone portability, so I would not use it.

My company gives prospective programmer a C test but our test is more of the, "here's a problem, how would you solve it" variety. It is not a, "here's some poorly written code, what would it do?" variety.

Bryan

1/14/2010 12:35 PM EST

I completely agree with Bryan above. I try to thoroughly understand all C code that I write, however I use only a small subset of all of the possible configurations of keywords and code. I don't try to be clever or tricky, and I don't try to see how many operations I can pack into one line of code. I opt for plain, boring, and easily readable. Thus, testing my knowledge on code that I never use really says very little about the robustness of code that I write.

1/14/2010 1:30 PM EST

After reading the article and the comments it raised, I took the test, got 9/10: I falsely put 'most ANSI C compilers' instead of 'all' for supporting 'volatile const'. Big deal!
This test only measures my knowledge of some obscure C trivia; as others have already written, I try very hard to avoid this kind of C statements anyway. I use parenthesis and typedefs to increase readability. This test says NOTHING about my real coder and problem-solving skills.

Sorry Michael, but I don't think you should try to read so much in those results. You are simply NOT measuring what you claim.

1/14/2010 1:45 PM EST

Improper programming is a consequence of using the Turing paradigm for control electronics in dynamic situations.

Turing's theory specifically addressed problems of a static nature. Using that static method for dynamics is destined to be problematic.

Has no one else questioned the fundamental means being used?

There are other, swifter, more efficient, and safer ways to produce and implement digital process controllers.

1/14/2010 1:59 PM EST

After reading the article I took the test.. And I wasn't very surprised to find that it mirrored the "test" Nigel Jones wrote nearly a decade ago: http://www.embedded.com/2000/0005/0005feat2.htm. This test doesn't measure any metric that I care about. Doing poor on it merely means you didn't study a textbook prior to taking it.. Or, you didn't have the original test open in another browser tab.

1/14/2010 2:16 PM EST

When I received a link to this story it reminded me that I had wanted to challenge Mr. Barr on one of the questions I had gotten wrong. The question asked what statement "accurately describes the intended effect" of a declaration. I read that question as "what did the programmer INTEND to do here" NOT how the compiler _actually_ interprets the declaration. Having seen this mistake made by many programmers (attempting to declare an array of pointers), I thought the "intent" was to create an array of 10 pointers to ints (which was my incorrect answer) while the correct answer is how the compiler _actually_ interprets the statement, which is a pointer to an array of 10.

I read the question that way because in others he clearly asks "what statement accurately describes the meaning of ...".

I also agree with Bryan's comments about declaring a variable both const and volatile which seems like an oxymoron to me.

Having said that, I do agree that the C language skill level of candidates I've interviewed over the last few years could be much better, but one of the problems that I see over and over again and bothers me more is clear communications skills.

I can't tell you how many times I've asked someone to describe an accomplishment listed on their resume and gotten vague or confusing answers. Or when trying to debug a problem with a coworker in another facility, find that their description of a problem is woefully incomplete requiring me to basically cross-examine them with a couple dozen questions to get complete and accurate information.

Clear communication is extremely important especially when dealing with complex designs and geographically distributed teams of people.

Nothing can disrupt a project like a situation where team A and team B are implementing modules that won't work together due to incomplete or ineffective communication.

Come to think of it, my complaint about that question on the quiz comes down to clear and effective communication too... Imagine that.

1/14/2010 3:41 PM EST

Part of the problem in achieving clear and straightforward communication: Programming is a spatial endeavor attempting, in many cases, to perform tasks in the spatio-temporal world.

Turing-type machines and their necessary software are constrained to work in the space-domain while the physical processes we wish to control inhabit the domains of space and time.

It has proved to be cumbersome and inefficient to effect process control in natural space-time with tools that only work in and upon space.

1/14/2010 4:39 PM EST

@Bryan: I don't see the problem with "volatile const" at all. It tells the compiler that there's a read-only chunk of data out there that is modified by an external process invisible to my code. A common example would be a read-only timer or counter register in a microprocessor. In theory, "volatile const" would prevent me from writing to that register, but force the compiler to disable possible optimisations on (near) adjacent reads.

1/14/2010 6:40 PM EST

I got 70%. That being said:

1) I still disagree that the "the most portable way to declare a C preprocessor constant for the number of seconds in a (non-leap) calendar year" is: #define SECONDS_PER_YEAR (60 * 60 * 24 * 365UL). If the target processor is 16-bits there may not be support for 'unsigned long'. Afterall, the question says "portable" ... and it says it's a C test ... not an "ANSI C" test.

2) Holy cow! The answer to: "Which of the following items should generally be declared using C's volatile keyword?" is "All of the Above". Are you kidding me? Is that the way you write code, Mr. Barr ... with "global variables in ISRs" ... or gang-banging "global variables in multi-threaded" apps? If that's the way you write safety-critical software ... and you call yourself an expert ... we're doomed! See to the beam in your own eye, Mr. Barr, before removing the speck from your neighbor's.

3) In general, the test is designed to determine what you don't know ... not what you know. Simple, readable, straight-forward code is the best. Leave the arcane trickery behind.

1/14/2010 9:06 PM EST

I got 90%, with the first question wrong. I agree to disagree that the "the most portable way to declare a C preprocessor constant for the number of seconds in a (non-leap) calendar year" is: #define SECONDS_PER_YEAR (60 * 60 * 24 * 365UL). If the target processor is 16-bits there may not be support for 'unsigned long', as the previous poster said.

I currently use "volatile global variables in ISRs" in a product and it seems the neatest and most efficient way of doing it.
The 8-bit system is just a big super-loop with no kernel or operating system. Most other globals are for reading IO port pins, and are accessed using well-named macros which make the code simple and easy to understand.

Sure one could hide the globals making them static and access them with accessor functions, but that leads down the dark slippery path of inefficient C++ coding;)

1/15/2010 2:03 AM EST

The issue isn't so much that one can, with sufficient discipline, write tolerably readable C, but how often one ends up having to decipher terse and cryptic C in order to maintain or modify a system or use third party code. Many people have had the experience often enough of trying to figure out what a fragment (even a single line) of C code actually means, let alone what it does. Groups of programmers can end up sitting around discussing a single declaration. Because it is not clear, people waste time and make mistakes that could have been avoided. C's terse, overloaded and involuted syntax positively encourages obscurity. I can't recall ever having this problem with Ada. This is hardly surprising. Ada is the result of an extensive design and review process. C was put together by a few people more or less on the spot in order to help do a particular job.

1/15/2010 2:34 AM EST

" "A variable declared static outside the body of a function can only be accessed by functions within the same module." Replace the word "module" with "function" and that statement is true. In my interpretation, a module is the C file in which the function is located which made the statement false in my mind."

But statics OUTSIDE the body of a function can only be accessed by functions within the same module/file. The question is correctly formulated, it assumes you know what the keyword static means on variables declared at file scope. That is, you know how to do private encapsulation in the C language. Very fundamental knowledge & a good question.


"I don't waste ROM space for a single const variable; I do that with #define."

Where did you think #defines were allocated then?


"why would I ever want to declare a variable as a "volatile const"?"

In almost every microcontroller used for embedded applications, there are read-only hardware registers. Though I agree that the question isn't really relevant for testing one's programming skill.

1/15/2010 2:51 AM EST

Regarding unsigned long, it must be supported by any compiler claiming to be a C compiler. The compiler is however free to make unsigned long a 16 bit variable. There is no C language but ANSI/ISO C. Testing people about their knowledge about non-standard compilers seems very much irrelevant to me.

" Holy cow! The answer to: "Which of the following items should generally be declared using C's volatile keyword?" is "All of the Above". Are you kidding me? Is that the way you write code, Mr. Barr ... with "global variables in ISRs"

Err... that is how you do it in C, it is the only way. You cannot communicate with an ISR without file scope variables, as ISRs lack parameters for natural reasons. A person who has at some point written an embedded application in the C language knows this. There is however no need to make those variables "global", you can make them static volatile.

Before I even started the test I already knew this question would appear, as it is -the- question for separating embedded programmers from the rabble. The question is testing your knowledge of the dangers of not making such variables volatile, ie avoiding introducing VERY subtle, intermittent bugs appearing because the optimizing compiler doesn't realise that the variable is ever changed elsewhere. If you don't know what bug I'm talking about, you shouldn't be writing embedded applications.

1/15/2010 3:21 PM EST

x &= ~0x01; This resets the right bit of x.

x & ~0x01; This leaves the value of x unchanged.

1/15/2010 4:04 PM EST

Well, having scored a perfect 10 on the test, I have to say that it seems to me to be an excellent way of distinguishing wheat from chaff..

1/15/2010 4:14 PM EST

I dont fully agree with the posted solution to the question asking the most portable way of implementing an infinite loop.

Lets recap:

1) while (1)
2) for (;;)
3) label goto label
4) All of the above

All of the above are legal syntax. However, are they all equally portable? Let's see.

Option #1 often generates a compiler warning.

Option #2 is subject to MISRA and ISO/IEC 9899 interpretation.

ISO/IEC 9899: TC2, Section 6.8.5.3 states :

"(1) The ... for ( clause-1 ; expression-2 ; expression-3 )
statement behaves as follows: ... expression-2 is the
controlling expression that is evaluated before each
execution of the loop body.

(2) Both clause-1 and expression-3 can be omitted. An
omitted expression-2 is replaced by a nonzero constant."


MISRA rule 13.5 which claims that the clause and expression parameters are optional seems to violate MISRA rule 13.7 which states:

"Boolean operations whose results are invariant ...
yield[ing] a result that can be proven to be always
' true' or always 'false' ... shall not be permitted."

Option #3 does not provide for job portability.

Im my opinion, option #1 is the most clear while option #2 allows for loop constructs with calculatable termination conditions (and should be used in such scenarios).

For the quiz, I chose option 2 since it does NOT generate a compiler warning. However in practice i use option 1.

Which option did you guys choose?

--Eric

Email references from:
Micrium Inc
Validated Software

1/16/2010 7:18 AM EST

They've got one of the questions really totally unacceptably wrong.

"#define SECONDS_PER_YEAR (60 * 60 * 24 * 365UL)" is worse than
"#define SECONDS_PER_YEAR (60 * 60 * 24 * 365)", as it gives a programmer a false hope that the whole expression would be promoted to a larger integer type (like 32bit on a 16bit machine) that would be able to hold the value of the constant. Because some embedded systems have 16bit ints by default, and 86400 * 365 doesn't fit in.

The problem is that multiplication is *left-associative* in C, and the type of the entire expression doesn't magically spill into the subexpressions. Try "long long int i = MAX_INT * MAX_INT * 1LL;" in MSVC or GCC, you'll get a warning and a wrong result. "1LL * MAX_INT * MAX_INT", however, works.

The whole point of the question is therefore compromised. If you have 16bit ints, then you get an overflow instead of 86400, _before_ you multiply it by 365. If you have 32bit ints then everything works as expected without specifying "UL" in the constant.

1/18/2010 1:00 AM EST

Let's face it, in this industry you can have a degree in Animal Husbandry and as long as you can hack a few lines of 'C' code you're a "Developer". Download your 'C' hack to a processor development board, hey you're an "Embedded Developer". Funny, I just packed up every issue of your magazine and stored it in the basement, almost caused a back injury (I'm only lacking a few issues). Why have I packed them away, because I just can't bear another article on how to do something correctly in 'C'. Your articles have been reduced to a bunch of 'C' fixes. Honestly I think the language should be outlawed. But hey, on the bright side, you can't spell "sucks" without 'c'.

1/18/2010 3:51 AM EST

I scored in the 60/70% range on the C/C++ tests. I've been programming in C since ~ '85, and C++ for over a decade. Recently I wrote myself a C++ parser for my parallel processing project (http://parallel.cc). I also work in Perl, Verilog and VHDL, and other stuff when I have to.

The question is not why are folks bad at C (or why don't they remember all the syntax, and compiler quirks), but why isn't there a better way of doing things after ~ 30 years.

Basically this is a failure in computer science (is it really a science?), and programmers should have better tools by now. Will we still be programming in C in another decade - I hope not.

Anyway, most professional software engineers know that architecture is more important than language, and use C/C++ because you won't be painting yourself into a corner if you do.

1/18/2010 3:55 AM EST

Regarding MISRA. I remember that the case with the loop was addressed at some point at the MISRA discussion forums, and that there were no particular advantage of while(1) compared to for(;;).

As you cite from the standard, expression 2 of a for loop is always non-zero if left empty, so therefore it is fully portable.

If you are ridiculously picky with the MISRA standard, while(1) is also forbidden as you must explicitly test expressions against zero (13.2). And there shouldn't be any unreachable code acording to MISRA, so you can't even use infinite loops in the first place. My point is, you can't always apply the rules literally to every situation, you should use them in the cases where they actually prevent non-portable and/or dangerous code.

Personally I always use for(;;) because this doesn't yield compiler warnings. while(1) gives you a warning about constant expression on good compilers. Meaning that you then must disable the warning in a compiler-specific way, which makes the code less portable.

---

label + goto should be fully portable (although ugly). Why wouldn't it be portable?

1/18/2010 5:41 AM EST

"The problem is that multiplication is left-associative in C"

Is it really? I think it is unspecified, and from what I found in the standard this seems to be true:

ISO 9899:1999 6.5:

"Except as specified later (for the function-call (), &&, ||, ?:, and comma operators), the order of evaluation
of subexpressions and the order in which side effects take place are both unspecified."


You remark is valid still however, one can't assume that the compiler evaluates the expression in a certain order. If it is evaluated left-to-right, it will indeed cause overflow on a 16 bit machine.

MISRA-C:s tough typecast rules would have eliminated this non-portable code.

1/18/2010 9:28 AM EST

In all honesty I took this test for fun and not for any demographic stating that I suck at programming C. I am not an embedded programmer I am a hardware designer looking into programming. My skills are very basic and it showed on this test. I've never even heard of half the questions never mind using them correctly. Maybe you should have had one question asking the skill level of the participant... Any way I would like to take the boot camp courses to improve my skill level.

1/18/2010 12:39 PM EST

I think the quiz is useful, but I don't agree with the conclusions. Based off the quiz's questions and others' comments, I believe an embedded software engineer could score 60% and still develop good quality code. Saying that 60% is similar to a grade of D- is misleading. I think it is more of an indication of the respondent not yet mastering the language.

The greatest authors have incredible command of language. Knowing the grammar and having a large vocabulary enable them to be creative and write works of art. Likewise, the best athletes have practiced fundamentals until they are second nature, they know the rules of the game backwards and forwards, and also seek to learn the tendencies of opponents.

An embedded software engineer should seek to have a broad and deep understanding of the language, whether it is C, C++, Ada, or whatever. Having that knowledge enables one to consider multiple solutions to problems and make better trade-off decisions. Having that knowledge allows one to address the larger issues of architecture, performance, portability, etc.

An inexperienced embedded software engineer will use a smaller subset of the language, and would probably miss several of the questions in the quiz. I don't think it necessarily follows that his code would be filled with errors. I think he ought to spend time in reference books ensuring his code is correct and learning the language. More experienced engineers should get more questions correct. An expert should get them all correct.

Just as many companies are too busy on projects to improve their processes, too many engineers are too busy developing code to master their programming language. This quiz provides some indication as to the level of mastery. Engineers can choose to dismiss it or learn from it.

2/22/2010 1:28 PM EST

I'll have to go along with the comments to the effect of, "Why are we still programming in C?" There have been much safer languages around for a long time now, and there are also chances to jump up an whole (not a half like C++ or Java) abstraction level with model-based tools and methods. I think where programmers (not just embedded) earn failing grades is in their failure to embrace technologies that could raise them out of the "mud-level" programming. Many of these technologies, while proven to work, are still relegated to niche status, because of the cost and maturity of the tools. This is due to low demand. Instead of priding ourselves on being good craftsmen of stone tools (or in the case of this article, shaming ourselves for being poor craftsmen of stone tools), we should be learning to work steel.

2/23/2010 2:13 PM EST

I took the test, didn't do all that well, but OTOH, most of the questions were about things that I just don't use. I think that RobFeldbruegge is right - we use what we need. If I need something more, I look it up, check examples, etc. then test functions to see what happens. If it looks good, I incorporate the new code. I have had many projects running just fine, and most of the problems have been hardware (mostly high-level EMI) related.
To lwrieman - we (I) use C because that's pretty much all there is for most small 8-bit micros. Perhaps if I was programming on an X86 platform, the question would have more validity, but I would bet that there are far more actual projects that use the cheaper 8-bitters than the multi-core monsters that might support multiple languages.
Another way of looking at it is to compare to spoken languages - I use English, despite it's quirks & inconsistencies, because that's what I learned at a young age, and I'm familiar enough to be able to express myself with it. I used to use assembler, but when I finally got C compilers for my projects, I never looked back. I know that there are issues, but most concern things that are not particularly relevant to what I do.

2/25/2010 1:12 PM EST

@JeremyE: VERY good post - you changed my mind! That situation is an excellent use of "volatile const"!

I came back to read some posts since I last commented and find some of the viewpoints interesting. It seems that Mr. Barr's intention wasn't so much to give us numerical grades or nitpick over compiler interpretations as to make us examine ourselves and our industry more deeply.

I think in light of the Toyota unintended acceleration problem our industry will be under more scrutiny than ever.

Embedded systems designers and programmers really should read Professor Gilbert's testimony. It's an excellent example of how experience and straightforward experimentation (also known as hacking - not a dirty word) can very quickly diagnose and characterize a problem.
You can read his testimony here:
http://energycommerce.house.gov/Press_111/20100223/Gilbert.Testimony.pdf

2/26/2010 12:10 PM EST

Pie Fight!

ooohh! I loves the blogosphere pie fight.

ok ... I will weigh in on this one.

I did not take the test. I saw absolutely no need to. Whenever I interview a prospective client, if I get a quiz... that is my cue to head on out the door. For me, there are really a limited set of questions that need to be answered:

1. How much money does your idea make?
2. How quickly can we make the money?
3. What are the threats to making the money in this way?
.
... well ... you get the idea.

As to Q & A, what most interests me is how quickly can the engineer spot and fix the problems? I have seen some incredibly abhorrent code and constructs that appear to work fine! ... and told by senior executives to not touch a thing!!!

After all ... most of the problems we fix are problems that were originally generated by ourselves. I call this the "Lassie Effect

src="http://i111.photobucket.com/albums/n138/krwada/animals/doggies/lassie.png" border="0" alt="Photobucket">

It only took Lassie one episode to get herself into trouble. Then it takes a dozen or so episodes for her to get herself out of trouble!

Heh!

2/26/2010 12:22 PM EST

Larry" target="_blank" style="">href="http://en.wikipedia.org/wiki/Larry_Wall">Larry Wall says it all...

Virtues of a programmer
1. Laziness - The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris.
2. Impatience - The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.
3. Hubris - Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience.

3/25/2010 10:08 AM EDT

Gentlemen, gentlemen... Let's just sum this whole discussion up simply with what I saw this time and so many times before in my 25 years of programming C for embedded and non-embedded applications, and elsewhere in life. The test was designed by a company wanting to sell us THEIR training, to show us how much we needed said training, and how little we remembered about the trivia associated with programming in C/C++. As such, the test did not address REAL knowledge and practice issues, but nuance and inuendo questions about code no self-respecting experienced professional embedded software developer would write. Sadly, Mr. Barr is missing the experience to see through this and published an article embellishing the results of the Netrino sales test. I do think Mr. Barr owes the profession an apology.

3/27/2010 12:42 AM EDT

I'm inclined to agree with Watkins as far as knowing the nuances of the language is concerned.While it is good to recollect the difference between *ptr++ and ++*ptr from the top of your head,the real challenge lies in designing the system, giving importance to the program flow,modularity,code re-use etc.In other words,'engineering' a solution rather than 'programming' it.I'm just novice but these are the issues that i think about before beginning to code.

A single test of 10 questions(i took the test a year and a half ago) doesn't say anything about the programmer's capability at all.I could prepare for a month,take a test for qualifying as a lawyer,ace it and yet not know anything 'real' about law.

11/9/2010 5:59 PM EST

I thought that taking this test would be an interesting thing to do as an embedded systems designer with something like 15 years experience. What I found out was that the test was not a test of embedded principles in general. Indeed, I believe the test to be flawed in that it is more of a trivial pursuit of C language. This test is not an accurate gauge of embedded programmers skills or education or abilities.

I hereby give the test itself a 'D' for not being the test it claimed to be!!

Indeed I agree with Mr. Watkins (posting above) in that the writer of this article failed to do what even some of our little children learn to do everyday.... not be fooled by advertisers!!!
hahahaha
Now I'm gonna go make an led breathe on my new dev kit!!!

1/10/2011 9:46 PM EST

I would disagree with Watkins. As a manager I've had my folks thank me for bringing in Michael Barr because of all of the things they learned from him.

A lot of respondents suggested that the quiz tested a rather esoteric level of knowledge and not what was practical. This attitude however misses the mark. I have seen teams of average programmers spend months trying to solve a difficult problem and get nowhere. I have also seen a "master" programmer solve that same problem in an afternoon. The difference between the two was that the "master" had more tools (i.e. knowledge and experience) to deploy in the resolution of that problem. I have seen this type of situation many, many times and yet very few programmers really make the effort to advance beyond their current level of skill. Believe me that everyone can improve their skills dramatically if they want to. I have seen that too.

Whether you get training from Michael's company or elsewhere is immaterial, the important point is that we must be aware of our ignorance if we are to take the steps to improve our skills. Michael's quiz goes a long way in providing us with that little bit of self knowledge.

9/22/2011 10:15 PM EDT

Several people commented on the use of the UL suffix, with varying degrees of accuracy. I cannot speak for all platforms, but any compiler implementation that claims to adhere to the ISO C standard must include an unsigned long int type. This type is guaranteed to fit a maximum value of 4294967295 - that is, be at least 32-bits (ISO 9899:1999 5.2.4.2.1).

Therefore, the answer from the quiz is correct, as any standards compliant compiler will be able to fit the value in an unsigned long. Additionally, the multiplication is being done in the preprocessor (on a host computer that is hopefully not as resource constrained as the embedded target), so there shouldn't be any concern of overflow in multiplying the first three terms.