Re: Warning for C Parameter Name Mismatch

[David Brown <david.brown@hesbynett.no>]

On 10/03/2019 07:11, Basile Starynkevitch wrote:
> 
> (I am reading the GCC mailing list in digest mode)
> 
> On 3/9/19 10:58 PM, gcc-digest-help@gcc.gnu.org wrote:
> 
>>
>> On Fri, 8 Mar 2019, Joel Sherrill wrote:
>>
>>> Can gcc report when the parameter name in a C prototype
>>> does not match that used in the implementation?
>>>
>>> int f(int x);
>>>
>>> int f(int y) {...}
>> I think this would be normal and expected - an installed header would use
>> a reserved-namespace name for the parameter while the implementation uses
>> a non-reserved name that's more convenient for use within the
>> implementation.  (Thus anything like this would only be useful if it can
>> know that it's e.g. OK to have __y and y as the names, and some code no
>> doubt uses other such conventions relating the two names.)
>> I can appreciate that a warning like this is not for everyone.  But 
>> /I/ would like and use such a warning for my own code. 
> May I remind to all that this is a typical case for you writing a GCC 
> plugin. You want a warning that few other people want, and that warning 
> is tied to your particular coding style.
> 
> You could avoid that warning by avoid naming the parameters in your 
> header files, so you would declare
> int f (int /*x*/); in your header file.
> 
> You might want to get a warning, but since it is not of general use (as 
> many explained, not using the same name in the header and in the 
> implementation of a given function parameter makes a lot of sense in 
> general, even if you dislike such as style) you really should consider 
> writing your own GCC plugin for that purpose.
> 
> How to write such a GCC plugin is a different question, and should be 
> asked as such.
> 
> Cheers.
> 

I fully agree that this is not a warning everyone will want - but I 
disagree with the idea that it is a specialist or unusual warning. 
Remember, no one is asking for it to be in -Wall or -Wextra.  gcc has 
many, many warnings available, and a large proportion of them will only 
be useful to a small proportion of users.  You could certainly say that 
of things like "-Wmissing-prototypes", "-Wmissing-declarations" and 
"-Wredundant-decls".  I fail to see that this suggestion is at all 
different.

In particular, I see this warning being of little use for large C / C++ 
applications with code split into multiple libraries.  But I see it as 
being of a good deal of use in small-systems embedded programming where 
you have a smaller code base, all compiled together in one project, and 
where coding conventions and styles are often strict.  That will apply 
to only a very small proportion of people programming for x86-64 targets 
- but a very high proportion of those programming for AVR, msp430, ARM 
Cortex-M, and most of the other targets of gcc.  It is easy to forget or 
underestimate the huge range of types of programming done with gcc - 
there are many of us for whom warnings like this would be a useful tool.

However, you are right that plugins could be a way to achieve this.  I 
think the Python plugin could be a good way to prototype features like 
this - and if it is useful, then it could be moved into gcc main.