I knew there was something up because long ago when developing for Arduino boards as part of a course, my mentor educated me on the difference of size of datatypes across different architectures.
So you think you know C? (2016)
71–80 of 344 posts
Re: So you think you know C? (2016)
#724/5, forgot that integer promotion is more complicated than what intuition would tell you. To be honest if was pretty obvious what the right answer was, but tried to answer honestly anyway ;)
Yeah I assumed short would be at least as big as a char and would this be comparing size of short against short. Didn’t realize it would get promoted to int.
Re: So you think you know C? (2016)
#73The better wording would be D) not enough information to give a definitive answer. It's like the old gotchya question; what is 1+1 ? of course the answer is it depends on if you are using binary or a base of integer >2.
Re: So you think you know C? (2016)
#74I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C. What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (…
GCC and many other compilers have been known to change the consequences of undefined behavior unpredictably when upgrading, changing compiler flags, etc. For some examples that matters.
Re: So you think you know C? (2016)
#75I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C. What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (…
Where the author goes wrong is in assuming that somehow "I don't know" can be a final answer to these things. No, it is absolutely fucking vital that you know how the compiler will pad your structures in C. Similarly to the "what size is an int" on your architecture - on an ATmega8 this is 16 bit, but the chip can't actually do all 16 bit operations in single instructions.
Re: So you think you know C? (2016)
#76I failed on one, number 4. I bravely assumed 16 bit integers cannot exist. Can anyone name a concrete platform/compiler where int is/was 16 bit. Or is this just a theoretical option left open by the spec?
I’ve worked with Arduinos where int was 16 bit.
Re: So you think you know C? (2016)
#77At the end of the test, the author talks about automation programming for a nuclear power plant. I don’t think I could ever sleep the same at night after writing something like that.
> I don’t think I could ever sleep the same at night after writing something like that
In these situations, you likely know your hardware and know your compiler, so you can actually provide an answer for 4 of the questions. The last one is a situation where someone should tell you not to get cute in the code review.
I wrote C in telecom and finance and in both places we enforced a rule: when you define a structure, put a comment after each element that says what you think the structure offset should be, and at the end of the structure #define a constant that says what you think the size of the structure should be. In a code review, if anyone noticed something that didn't look right, you could talk about it. In testing, you could also check that sizeof(foo_s) == FOO_S_SIZE and fail if it wasn't.
In some of our code, we would test the size of various types and structures on startup and immediately exit if they weren't what we expected. We'd print type sizes to logs to help debugging if there was ever a problem. We were supporting a single code base that ran on big endian, little endian, X86, Itanium, SPARC, ARM. Compilers change, but automated tests of type and structure sizes catch things immediately.
It may sound like a lot of work, but it actually isn't at all. It also helps a lot with long-term maintainability.
Re: So you think you know C? (2016)
#78It is not difficult to overcome these limitations of C by typedef definitive types like signed int32, unsigned int8 and so on. Many embedded C .h have that as a standard way of clearing things up. of course you can always sizeof(int) or whatever. (BTW this quiz or one like has been around a long time, but still a good reminder).
Re: So you think you know C? (2016)
#79I found it an amusing excrcise, if not terribly relevant, even as someone who spends 90% of his dev time in C. What rubs me about these sorts of articles is they make some presumption about the importance and nessecisity of writing truely portable C, as if the "C Standard" were in and of itself a terribly useful tool. This is in contrast to where I live most of the time which is "GCC as an assembler macro language" (…
Knowing what the standard says and keeping to it as much as possible is important because every now and then, a major compiler finds some exciting new way to optimise code based on undefined behaviour, and breaks code that assumed GCC would always do some seemingly obvious reasonable thing it did when the author tested it.
Re: So you think you know C? (2016)
#80The real answer is, all 5 questions don't compile so they don't return anything.