Skip to content

Comment on Why are embedded systems software developers getting a D- in C?

Comments

Possible answer to the post title: Their quiz-taking webapp is terrible. You can't retake the quiz or review previous questions, and can only try each question once, and if you go back and choose a different radio button as an answer for a previous question, it answers the current question instead (basically throwing away your answer).

So maybe people just couldn't use their damn webapp.

Several of their questions:

Which of the following is the most portable way to declare a C preprocessor constant for the number of seconds in a (non-leap) calendar year?

    #define SECONDS_PER_YEAR 60 * 60 * 24 * 365
    #define SECONDS_PER_YEAR 60 * 60 * 24 * 365;
    #define SECONDS_PER_YEAR (60 * 60 * 24 * 365UL)
    #define SECONDS_PER_YEAR (60 * 60 * 24 * 365)
Which of the following is the most flexible way to declare a C preprocessor macro that takes two arguments and returns the smaller of their two values?
    #define MIN(A, B) ((A) < (B) ? (A) : (B))
    #define MIN(A, B) { if (A < B) A; else B; }
    #define MIN(A, B) ((A < B) ? A : B)
    #define MIN(A, B) A < B ? A : B;
Which of the following constructs can be used to create a portable infinite loop in C?
    while (1) { ... }
    for (;;) { ... }
    loop: ... goto loop;
    All of the above
And then they asked a question which says "what was the intended effect of [some terribly misleading line of C]" and I became fed up, because I have no idea what the intent was, even if I could figure out the actual behaviour.

I don't like any of those MIN macros, and that question irritated me. Until C overhauls its macro system, the only good MIN macro is the kind that's actually a function. A good compiler will inline that for you anyway, probably, and most compilers let you declare functions inline in C.

I think their test is best described "If you're not looking up the answers to half of these, you're a shitty, arrogant, and dangerous embedded programmer because you are going to make mistakes, and those mistakes are likely going to be subtle"

I didn't see a lot of questions here that needed "looking up".

Most embedded C devs know what "volatile" does, because if you get that wrong your program crashes.

Very few developers know how to craft hygenic cpp macros, but since the question didn't ask about hygiene, I wouldn't expect anyone to feel like they should "look it up". You kind of either know it or you don't.

If anything, the problem with this quiz is that it was far too superficial.

1. C Compiler Compliance question

2. Behavior of UL on a non-32 bit system according to modern standards and the compliance of compilers to that standard

and

3. That the declaration of a pointer to a constant int array was actually that. This is a prime case for using C-Decl or whatever the name of the program is that is mentioned in K&R, (or at least some googling).

All three of these should be looked up. If you have experience with a particular system that uses the last item a lot, then you possibly should not be looking that up. The other two items most assuredly should be looked up. Very very few people have the experience of writing code that works on all sorts of systems using processors of differing word size while compiling on modern compilers. Only those few souls shouldn't be looking up the answers to #1 and #2

The compiler compliance question would be good to look up if it was easy to look up. It is in fact just a bad question (I got it wrong, saying "most" where they expected "all").

Embedded developers don't usually need to look up word size issues; it's hard to do your day to day job if you don't know what an "int" is. Nevertheless, that issue actually has very little to do with the question, which you answer simply by choosing the constant that is most specific about its storage requirements.

If you don't know how const works, you probably don't use const much; keeping code const-correct (a waste of time, for what it's worth) drills this stuff into you pretty quickly. Again, it's not a great embedded dev question, but it assessess what it means to assess: whether you know how const works.

^ Not being bitter, have worked with embedded engineers who don't believe they're wrong about stupid points which if they'd looked up would have seen that they're 100 miles off course.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.