I disagree. I feel that knowing what might happen demonstrates that the individual has considered the design of C carefully and taken the time to find out how it is, and why it is the way it is. I think that sort of knowledge always leads to better code in the language.

The man in the example might know to "never write code like" a variable incrementing and assigning to itself again, but there might be other, more subtle pitfalls in design and implementation that he succumbs to because he hasn't given much thought to all the different ways that the rules of the language can interact.

I agree - the girl's knowledge might be a net win, provided she doesn't go out of her way to use it.

Note that it's not all stuff that you can just look up: although you can look it up, it might not be obvious that it needs to be looked up. I had no idea there was a difference between `int f()` and `int f (void)`, and if that ever caused problems for me I doubt I would have been able to track it down easily.

"A gentleman is someone who knows how to play the bagpipes, and doesn't."

I think there is a point of expected knowledge though, as somethings really won't matter in the long run. It's been a long long time since I've touched C, but if I remember right a big issue with int main() & int main(void) is that if you don't have the void to tell the compiler that main takes no argument then you can cause lots of micro-controllers running your code to crash. This fact makes the void knowledge more important for micro-controller programmers then it does for Windows programmers (although it's very simple knowledge that a lot of people state).

Sure, but would you really care whether someone knew off the top of their head that %zu is the escape sequence for size_t? Some of the stuff she shows off is pretty arcane, though pieces of it are actually useful.

Understanding the memory model and execution model is a big plus, because it lets you write correct and efficient code (and if you are using C you care about correctness and efficiency). Recalling arcana about the C99 standard is just overkill and asking someone to pull stuff like that out of a hat in an interview is asking too much IMO.

I have to work with folks who confuse size_t with int, and as a result they have overflow bugs depending on whether O_LARGEFILE is in use. So yes, I care. Not because printf format strings are terribly important, but because understanding and adhering to the type system is essential to write bug-free software.

If they get overflow errors then your build process does not have the right warnings enabled/logged.

Suggestion: enable -Wall and treat warnings as errors.

Of course. You and I know they're doing it wrong, however sirclueless suggested above that type correctness is "arcane" and asks if "we would really care" when it comes to type issues in printf format strings.

Handily, gcc has -Werror, which turns all warnings into errors. So -Wall -Wextra -Werror should catch most things.

Except if you're using gcc (mingw) on Windows:

gcc -v shows that it's been configured with --disable-werror

If you're being sensible and using -Wall with gcc, it will pick up the %zu thing anyway:

sizeof-test.c: In function ‘main’: sizeof-test.c:5:3: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long unsigned int’

Compilers have warnings so that you don't have to remember archaic bits of C. :)

Learning arcane trivia is a side effect of learning the necessary stuff.

Yes, I would care. Someone who didn't know might notice the sizeof() and note that it returns size_t, but not know what to do about it, and end up saying "screw it" and just using "%d", which is not portable, and the program might crash when compiled for a different system. It might even run on his sytem today, but not tomorow, or run in the debug image but fail in production. I've seen this and similar things happen many-a-time.

Pet peeve alert: sizeof is not a function. It's a unary operator.

The parenthesis you usually see after it are part of the argument, which for type names looks like a cast to the type in question. Like any other cast, the syntax is the type name in parenthesis.

Apologies if you already knew this.

> I agree - the girl's knowledge might be a net win, provided she doesn't go out of her way to use it.

It's only a net win if the price is right and the project requires such knowledge (in the case of C, mostly likely the trade-off would be a bad one, experience at that level comes at a steep price, fixing bugs due to a lack of knowledge about what happens 'under the hood' is expensive too...).

I agree. It's a little like a Java programmer knowing JVM bytecode: definitely not _needed_ but you'll be much better at understanding why (for example) some code structs are more efficient than others.

Knowing what happens when you fail to initialize a static variable may be useful for debugging when you (or someone else) accidentally fails to initialize a static variable.

Well, you can't fail to initialize a static variable, so maybe you meant accidentally initializing it to the wrong value.