[robertgraham]

The first two answers are 8 and 0.

They are technically `undefined` according to the C standard, but are the behavior of every mainstream compiler. So much of the world's open-source code depends upon these that it's unlikely to change.

Using clang version 15.0, the first 2 produce no warning messages, even with -Wall -Wextra -pedantic. Conversely, the last 3 produce warning messages without any extra compiler flags.

The behavior of the first two examples are practically defined even if undefined according to the standard.

Now, when programming for embedded environments, like for 8-bit microcontrollers, all bets are off. But then you are using a quirky environment-specific compiler that needs a lot more hand-holding than just this. It's not going to compiler open-source libraries anyway.

I do know C. I knowingly write my code knowing that even though some things are technically undefined in the standard, that they are practically defined (and overwhelmingly so) for the platforms I target.

[GuB-42]

> Now, when programming for embedded environments

Something that a lot of C programmers do...

Most people who write for typical desktop and mobile computers don't do C. They tend to do C++ or other, higher level languages. Those who write C tend to do either quirky embedded code, or code that is highly portable, in both cases, knowing about such undefined or implementation defined behavior is important.

If you intend on relying on such assumptions, make it explicit, for example using padding, stdint, etc... On typical targets like clang and gcc on Linux, it won't change the generated code, but it will make it less likely to break on quirky compilers. Plus, it is more readable.

[notfed]

You start off confident that the first answer is 8.

Then you admit that the microcontroller world presents exceptions.

You've now arrived at "I don't know" the answer.

The article never said "using mainstream C compilers".

[ryao]

The first 4 are implementation defined rather than undefined.

That said, warnings do not necessarily mean that the code is invoking undefined behavior. For example, with if (a = b) GCC will generate a warning, unless you do if ((a = b)). The reason for the warning is that often people mean to do equality and instead write assignment by mistake, so the compilers warn unless a second set of braces is used to signal that you really meant to do that.

[o11c]

In the cases involving overflow, it's implementation-defined whether there's undefined behavior.

[turminal]

> The first 4 are implementation defined rather than undefined.

Third and fourth are only defined in some implementations.

[addaon]

Every mainstream compiler targeting a 32 or 64 bit platform.

Have we crossed the point yet that the majority of new microprocessors and microcontrollers sold each year are 32+ bit yet? Most devices I’m familiar with still have more 8 and 16 bit processors than 32 and 64 bit processors (although the 8 bit processors are rarely programmed in C).

[1over137]

>no warning messages, even with -Wall -Wextra -pedantic

A better test is -Weverything.