Re: Warning for C Parameter Name Mismatch

[Basile Starynkevitch <basile at starynkevitch dot net>]

On 3/10/19 12:54 PM, David Brown wrote:
> 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.

In the long term, the question becomes philosophical. I would be really 
happy if every future GCC release would come with a small set of 
"example" plugins for various unusual warnings. And I even think that 
such an approach will favor outside people to write plugins for their needs.

I am not so sure that making an even larger cc1plus binary is wanted.

Of course, I am making the hypothesis that plugins are as necessary as 
directories to host GCC.

Cheers


--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France