* Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?
2022-11-10 19:16 ` Florian Weimer
@ 2022-11-10 23:05 ` Jonathan Wakely
2022-11-10 23:33 ` Joseph Myers
2022-11-11 9:21 ` David Brown
2 siblings, 0 replies; 6+ messages in thread
From: Jonathan Wakely @ 2022-11-10 23:05 UTC (permalink / raw)
To: Florian Weimer; +Cc: Marek Polacek, gcc
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?
2022-11-10 19:16 ` Florian Weimer
2022-11-10 23:05 ` Jonathan Wakely
@ 2022-11-10 23:33 ` Joseph Myers
2022-11-11 9:21 ` David Brown
2 siblings, 0 replies; 6+ messages in thread
From: Joseph Myers @ 2022-11-10 23:33 UTC (permalink / raw)
To: Florian Weimer; +Cc: Marek Polacek, gcc
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?
2022-11-10 19:16 ` Florian Weimer
2022-11-10 23:05 ` Jonathan Wakely
2022-11-10 23:33 ` Joseph Myers
@ 2022-11-11 9:21 ` David Brown
2 siblings, 0 replies; 6+ messages in thread
From: David Brown @ 2022-11-11 9:21 UTC (permalink / raw)
To: Florian Weimer, Marek Polacek; +Cc: gcc
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread