Can't even make the test. Which version of C? Which platform? Under DOS in the 90's, the answer to the first question would have been 3, it's not even proposed in the options.
So you think you know C? (2016)
161–170 of 344 posts
Re: So you think you know C? (2016)
#162Re: So you think you know C? (2016)
#163Can't even make the test. Which version of C? Which platform? Under DOS in the 90's, the answer to the first question would have been 3, it's not even proposed in the options.
Each of the questions has exactly one answer that is correct regardless of version and platform.
Re: So you think you know C? (2016)
#164My answer to a lot of these questions is "If you write code like this and check it in to our corporate repository, I will cut out your heart and make you eat it."
Re: So you think you know C? (2016)
#165My answer to a lot of these questions is "If you write code like this and check it in to our corporate repository, I will cut out your heart and make you eat it."
Well there may be some use for the code in question 1.
Re: So you think you know C? (2016)
#166Earlier quoted context omitted.
> In some of our code, we would test the size of various types and structures on startup This is one of the things that C++ has actually improved a lot recently: doing this with static_assert is much nicer in terms of catching problems early... And yes, it's great for long-term maintainability.
C has had standardized static assert since the C11 spec was released. See [1] for instance. [1]: https://stackoverflow.com/a/7287341
I never thought I’d hear myself saying this, but that syntax is uglier than C++’s.
Re: So you think you know C? (2016)
#167UB nasal demons etc etc. But often we encounter UB in code that's already shipped. So it's good to have an intuition about what machine code was actually emitted, for example when deciding if a crash report is due to this particular UB, or not.
Or you could just look at the binary you shipped: by the time it’s compiled, you don’t really have to deal with undefined behavior.
Re: So you think you know C? (2016)
#168I 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?
Why couldn't they? C had already existed for a couple of decades when 32-bit machines started getting popular. `int`, as the default integer type, usually is the size of the machine word for best performance. It would make no sense to have slow, emulated 32-bit ´int`s on a 16-bit system, never mind 8-bit ones.
Re: So you think you know C? (2016)
#169Earlier quoted context omitted.
Compile it, look at the assembly. You can know. The answer will vary from place to place, but it isn't non-existent.
With what compiler? Targeting what architecture? The question is underspecified. "I can't know" is correct.
Q: What is a leaky partial abstraction of the C standard?
Ans: A compiler.
Re: So you think you know C? (2016)
#170What are the best strategies to cope with the undefined areas in C?
The best one is to not write C. The second best is probably to read the standard papers, be very careful (perhaps using a secure style guideline) and making generous use of tooling to help you catch mistakes.