The quiz is exactly right: yes, the answers are all "I don't know" because the behavior is either implementation defined or undefined for each of them, and a couple of these reflect mistakes that I have had to point out in code reviews in recent years: expressions with multiple side effects without a sequence point, and shifting a N bit integral type by N bits (yes, that is undefined because some processor instruction sets mess up that case). C and C++ programmers need to be taught that they must not write that.

> C and C++ programmers need to be taught that they must not write that.

Things have stabilized quite a while ago. 99% of people who write C or C++ in 2024 will never use any computers where sizeof(int) != 4, or big endian processors, or systems where floats don’t conform to IEEE-754 standard.

Why shouldn’t they write code which requires these particular details from their compiler and the target processor?

I'd say there's no issue with writing such code, so long as it's protected by a compile-time assertion.

That said, if you use a variable-width integer type (`char`, `short`, `int`, `long`, `long long`) instead of a fixed-width type (`int32_t` & such) for anything other than passing parameters to existing libraries (including the standard library) I'd say you're Doing It Wrong. If you actually intend to have a variable-width, use one of the `_least` or `_fast` types to make it clear that you didn't just screw up.

One thing I think C++ (or at least, most C++ users) gets right is suggesting that you should use 'auto' if you don't really care that much about bit width, and the specified sizes otherwise.

Thankfully C23 takes this approach, although it'll probably take forever until it's as adopted as widespread as C99 is now, and that's still not widespread enough.