I 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?
So you think you know C? (2016)
31–40 of 344 posts
Re: So you think you know C? (2016)
#32Re: So you think you know C? (2016)
#33Re: So you think you know C? (2016)
#34At 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.
Particularly writing it in C... It isn't a language well suited to be fully defined (see this very article for why), and no, Rust/Go aren't either. But Ada derivative or Haskell perhaps, there's some amazing tooling for safety critical systems and the languages themselves lend themselves to exposing side-effects.
Ada, maybe? I don't know enough about it to comment. You definitely don't want to use Haskell for that sort of work load, though, at least not directly. Laziness-by-default is precisely the sort of hard-to-reason-about logic you don't want in that sort of application.
That said, if I I had no alternative but to try and tackle this problem, I would seriously consider a strategy where I would write a Haskell program that would generate the actual program (potentially in ASM directly) for me.
Re: So you think you know C? (2016)
#35I 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?
AVR, so certain Arduinos. On an Arduino Uno, sizeof(int) returns 2.
Re: So you think you know C? (2016)
#36 int a=1, b=2, i, j;
i = a += 2, a + b;
j = (a += 2, a + b);
Whats the value of a, b, i, j? Hint: i and j are different.Which begs the question, why does C have those features in the first place? The only C code where it's reasonably common seems to be in crypto algorithms.
Re: So you think you know C? (2016)
#37Didn't quite know the purpose of the test, there's a difference between code for any machine and any compiler and gcc running on some vanilla x86, which is pretty common, and could have been the content (ex: you say it's undefined, that's obvious, everyone knows that already, but it's still deterministic... Here's a breakdown of what happens in practice, blah blah blah). There's a real difference between the kind of "knowing" here and say the kind of "knowing" with unallocated pointers.
If it said "esoteric implementation on exotic hardware" then it's easy, you know what they are trying to do. If it said C89 you also know what's up. But how it's presented, it's a guess.
This was endemic throughout schooling. Instructors would say "just do your best" and I'd be like "wtf? There's like 2,3, maybe 4 perspectives on this with different answers depending on how clever you're trying to be or what you're trying to get at... Might as well put "I'm thinking of a number 1 through 5" on the exam".
Re: So you think you know C? (2016)
#38Re: So you think you know C? (2016)
#39There are a few problems with the questionnaire. "I don't know" is pretty generic choice to be given/choosen. Say for example, in question 5, the statement "return i++ + ++i;" is undefined, because the value of i is read and modified twice in a single sequence point (and of course, the order of addition is unspecified), which is not allowed in C. So the answer is "Undefined." (The explanation given in the page not ac…
Re: So you think you know C? (2016)
#40“I don’t know” is not the right answer. I do know. I know the answer to be “Unspecified”.