[pascal_cuoq]

This list contains several invalid items mixed with the good ones. It starts:

     Why does the following code return 0 for most values of x? (This should be easy.)

      int x;
      return x == (1 && x);

The answer is that the code can return what it wants or make demons fly out of your nose, because using the automatic variable x without initializing it is essentially UB (UB in simple words in C89, unarguably UB in C11 because the address of x is not taken, and debatable in C99 but only because of poor choices of words). But I don't think this is the answer that the authors are thinking of.

“It is UB” also applies to “(1 - sizeof(int)) >> 32”, the next question, on ILP32 architectures that were still prevalent when this page was written (shifting an integer type of width 32 by 32), regardless of the discussion the authors want to have about the type of sizeof(t).

“Functions and function pointers are implicitly converted to each other” is one way to describe what the C standard actually says, but that makes it look more complicated than it is. In reality, functions decay to pointers to function in the same way that arrays decay to pointers-to-first-element, and if you are familiar with the latter, it's a good way to understand the former. Only function pointers can be applied. When you write “f(x)”, f first decays to pointer to function, and then is applied. The reason you don't need to dereference a pointer-to-function p when you apply it as “p(x)” is NOT that p will be converted implicitly to a function, but that function application expects a pointer to function.

The first example in 16.3 is also Undefined Behavior, regardless of the target architecture, because the type of “3” is always “int”, so it's a poor illustration of the VC compiler bug they are referring to.

[shantnutiwari]

I came here to say this-- for many of the questions, the answer is Undefined Behaviour.

The very 1st one-- I havent done embedded C for a long time, but the 1st thing I was taught was *not* to assume uninitialised variables would be set to 0. The author probably tested on a known safe (read lab like) system.

>> can return what it wants or make demons fly out of your nose,

Indeed, this is the correct answer.

Most the questions on the page seem to be "Let's do weird crap highly dependent on the architecture/compiler, using undefined behaviour, and LOL, we can then blame C"

And not defending C here at all, moved away from it years ago. But there are better criticisms than this

[MauranKilom]

It explicitly says "for most values of x", i.e. it assumes x to be initialized (but doesn't show so in the code).

[leetcrew]

not a good way to give the example then. most c or c++ developers are going to start twitching uncontrollably the second they see a variable declared uninitialized and then immediately read from.

[dataangel]

they're just doing a poor job of saying assuming x is declared an int somewhere else why would this be true