Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

[Florian Weimer <fweimer@redhat.com>]

* Gerald Pfeifer:

>>  This mostly happens in function definitions
>> +that are not prototypes
>
> Naive questions: Can definitions really be prototypes (in C)?

Yes, I think so: definitions can be declarations, and function
prototypes are declarations.  The standard uses the phrase “function
definition that does not include a function prototype declarator”.
Should I write “old-style function definition” instead?

>
>> +declared outside the parameter list.  Using the correct
>> +type maybe required to avoid int-conversion errors (see below).
>
> Something feels odd with this sentence?

The fix is to write “may[ ]be“, as suggested by other reviewers.

>> +Incorrectly spelled type names in function declarations are treated as
>> +errors in more cases, under a
>> +new <code>-Wdeclaration-missing-parameter-type</code> warning.  The
>> +second line in the following example is now treated as an error
>> +(previously this resulted in an unnamed warning):
>
> What is an "unnamed" warning? Can we simply omit "unnamed" here?

A warning not controlled by a specific -W… option.  I've made the
change.

>> +GCC will type-check function arguments after that, potentially
>> +requiring further changes.  (Previously, the function declaration was
>> +treated as not having no prototype.)
>
> That second sentence uses double negation, which logically is the same as 
> just the original statement.

Other reviews suggests to change it to “not having [a] prototype”.

>> +<p>
>> +By default, GCC still accepts returning an expression of
>> +type <code>void</code> from within a function that itself
>> +returns <code>void</code>, as a GNU extension that matches C++ rules
>> +in this area.
>
> Does the GNU extension match C++ (standard rules)?

Yes.  Should I write “matches [standard] C++ rules”?

Thanks,
Florian