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

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

[Florian Weimer]

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.

Is this interpretation correct?

Sorry if this questions this is more appropriate for the gcc-help list.

Thanks,
Florian

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

[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.
 
> Is this interpretation correct?
> 
> Sorry if this questions this is more appropriate for the gcc-help list.
> 
> Thanks,
> Florian
> 

Marek

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

[Florian Weimer]

* 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.

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 wonder how C++ handles this.

Thanks,
Florian

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

[Jonathan Wakely]

On Thu, 10 Nov 2022 at 19:17, Florian Weimer via Gcc <gcc@gcc.gnu.org> 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.

As long as a diagnostic is issued, the invalid program can be
successfully translated. Presumably the implementation defines what it
means in that case, because it's not a valid C program, so the
standard no longer applies. As you say, that's undefined by omission.


> 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 wonder how C++ handles this.

Similarly. We don't have constraint violations, we have "diagnosable
rules", see [intro.compliance.general]. If a program contains a
violation of a diagnosable rule, the implementation must issue a
diagnostic message. What it does after that is up to the
implementation, the program has left the realm of valid C++ code.

It's not exactly easy for a user to know whether a given compiler
warning was issued because of a constraint (or diagnosable rule)
violation, or because e.g. the compiler thinks extra parens or more
consistent indentation would be a good idea. In the former case, the
program has undefined behaviour (strictly speaking, but in practice
the implementation might "define" its behaviour) and in the latter
case it doesn't. -pedantic-errors can help, as that turns the former
class into errors.

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

[Joseph Myers]

On Thu, 10 Nov 2022, Florian Weimer via Gcc wrote:

> 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.

The rule (for C) is that any diagnostic required by the standard should 
either be a warning or a pedwarn (where -pedantic-errors turns the latter 
but not the former into errors).

There are a few cases where -pedantic enables warnings that aren't 
pedwarns because they aren't required by the standard; for example, 
-Wformat -pedantic warnings for use of printf format extensions.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[David Brown]

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
> 
>