Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

[David Brown <david@westcontrol.com>]

On 10/11/2022 20:16, Florian Weimer via Gcc wrote:
> * Marek Polacek:
> 
>> On Thu, Nov 10, 2022 at 07:25:21PM +0100, Florian Weimer via Gcc wrote:
>>> GCC accepts various conversions between pointers and ints and different
>>> types of pointers by default, issuing a warning.
>>>
>>> I've been reading the (hopefully) relevant partso f the C99 standard,
>>> and it seems to me that C implementations are actually required to
>>> diagnose errors in these cases because they are constraint violations:
>>> the types are not compatible.
>>
>> It doesn't need to be a hard error, a warning is a diagnostic message,
>> which is enough to diagnose a violation of any syntax rule or
>> constraint.
>>
>> IIRC, the only case where the compiler _must_ emit a hard error is for
>> #error.
> 
> Hmm, you could be right.
> 
> The standard says that constraint violations are not undefiend behavior,
> but of course it does not define what happens in the presence of a
> constraint violation.  So the behavior is undefined by omission.  This
> seems to be a contradiction.
> 

Section 5.1.1.3p1 of the C standard covers diagnostics.  (I'm looking at 
the C11 version at the moment, but numbering is mostly consistent 
between C standards.)  If there is at least one constraint violation or 
syntax error in the translation unit, then the compiler must emit at 
least one diagnostic message.  That is all that is required.

The C standard does not (as far as I know) distinguish between "error 
messages" and "warnings", or require that diagnostics stop compilation 
or the production of output files.

So that means a conforming compiler can sum up all warnings and errors 
with a single "You did something wrong" message - and it can still 
produce an object file.  It is even allowed to generate the same message 
when /nothing/ is wrong.  The minimum behaviour to be conforming here is 
not particularly helpful!

Also note that gcc, with default flags, is not a conforming compiler - 
it does not conform to any language standards.  You need at least 
"-std=c99" (or whatever) and "-Wpedantic".  Even then, I think gcc falls 
foul of the rule in 5.1.1.3p1 that says at least one diagnostic must be 
issued for a syntax or constraint violation "even if the behaviour is 
explicitly specified as undefined or implementation-defined".  I am not 
entirely sure, but I think some of the extensions that are enabled even 
in non-gnu standards modes could contradict that.

I personally think the key question for warnings on things like pointer 
compatibility depends on whether the compiler will do what the 
programmer expects.  If you have a target where "int" and "long" are the 
same size, a programmer might use "pointer-to-int" to access a "long", 
and vice-versa.  (This can easily be done accidentally on something like 
32-bit ARM, where "int32_t" is "long" rather than "int".)  If the 
compiler may use this incompatibility for type-based alias analysis and 
optimise on the assumption that the "pointer-to-int" never affects a 
"long", then such mixups should by default be at least a warning, if not 
a hard error.  The primary goal for warnings and error messages must be 
to stop the programmer writing code that is wrong and does not do what 
they expect (as best the compiler can guess what the programmer expects).

The secondary goal is to help the programmer write good quality code, 
and avoid potentially risky constructs - things that might work now, but 
could fail with other compiler versions, flags, targets, etc.  It is not 
unreasonable to have warnings in this category need "-Wall" or explicit 
flags.  (I'd like to see more warnings in gcc by default, and more of 
them as errors, but compatibility with existing build scripts is important.)


> I assumed that there was a rule similar to the the rule for #error for
> any kind of diagnostic, which would mean that GCC errors are diagnostic
> messages in the sense of the standard, but GCC warnings are not.

I believe that both "error" and "warning" messages are "diagnostics" in 
the terms of the standard.

As I said above, the minimum requirements of the standard provide a very 
low bar here.  A useful compiler must do far better (and gcc /does/ do 
far better).

> 
> I wonder how C++ handles this.
> 
> Thanks,
> Florian
> 
>