c - technical legality of incompatible pointer assignments

Question

The C11 standard ISO/IEC 9899:2011 (E) states the following constraints for simple assignments in §6.5.16.1/1:

One of the following shall hold:

• the left operand has atomic, qualified, or unqualified arithmetic type, and the right has arithmetic type;
• the left operand has an atomic, qualified, or unqualified version of a structure or union type compatible with the type of the right;
• the left operand has atomic, qualified, or unqualified pointer type, and (considering the type the left operand would have after lvalue conversion) both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right;
• the left operand has atomic, qualified, or unqualified pointer type, and (considering the type the left operand would have after lvalue conversion) one operand is a pointer to an object type, and the other is a pointer to a qualified or unqualified version of void, and the type pointed to by the left has all the qualifiers of the type pointed to by the right;
• the left operand is an atomic, qualified, or unqualified pointer, and the right is a null pointer constant; or
• the left operand has type atomic, qualified, or unqualified _Bool, and the right is a pointer.

I am interested in the case in which both sides are pointers to incompatible types different from void. If I understand correctly, this should at the very least invoke UB, as it violates this constraint. One example for incompatible types should be (according to §6.2.7 and §6.7.2) int and double.

Therefore the following program should be in violation:

int main(void) {
  int a = 17;
  double* p;
  p = &a;
  (void)p;
}

Both gcc and clang warn about "-Wincompatible-pointer-types", but do not abort compilation (compilation with -std=c11 -Wall -Wextra -pedantic).

Similarly, the following program only leads to a "-Wint-conversion" warning, while compiling just fine.

int main(void) {
  int a;
  double* p;
  p = a;
  (void)p;
}

Coming from C++, I expected that either of those test cases would require a cast to compile. Is there any reason why either of the programs would be standards-legal? Or, are there at least significant historic reasons for supporting this code style even when disabling the entertaining GNU C extensions by explicitly using -std=c11 instead of -std=gnu11?

Answer 1

Is there any reason why either of the programs would be standards-legal?

These programs are not "standards-legal". They contain constraint violations and you already quoted the right text from the standard.

The compilers conform to the standard by producing a diagnostic for constraint violation. The standard does not require compilation to abort in the case of a constraint violation or other erroneous program.

It doesn't say in as many words, but the only reasonable conclusion is that any executable generated as a result of a program containing a constraint violation has completely undefined behaviour. (I have seen people try to argue otherwise though).

Speculation follows: C (and C++) are used for many purposes; sometimes people want "high level assembler" for their machine and don't care about portability or standards. Presumably the compiler vendors set the defaults to what they think their target audience would prefer.