Re: Warning for C Parameter Name Mismatch

[David Brown <david dot brown at hesbynett dot no>]

On 09/03/2019 03:23, Eric Gallager wrote:
> On 3/8/19, David Brown <david.brown@hesbynett.no> wrote:
> > On 09/03/2019 00:06, Joseph Myers 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.
> >
> > The kind of headers which would specifically use reserved or otherwise
> > unusual parameter names are things like library headers - and you will
> > not be compiling the implementation source code, and thus won't get a
> > mismatch.  A warning like this would be used with your own header/source
> > combinations - where your implementation is #include'ing the unit's
> > header as a way of checking that you've got the function name and
> > parameter types correct.  This warning would add parameter names to the
> > things that are checked.
>
> How would it handle the case where the parameter name is missing
> entirely from the prototype? I see a lot of header files with their
> prototypes written like that.
>
> e.g.
>
> int f(int);
>
> int f(int y) {...}

That would be a warning, I would say.

	int f(int);

	int f(int) { ... }

would be fine in C++.  (And maybe allowed as a gcc extension in C?)


To me, this whole thing has two purposes.  It is to encourage 
consistency and avoid errors like having "moveto(int x, int y)" in the 
header and "moveto(int y, int x)" in the implementation file.  It is not 
nearly as good as named parameters would be, but it's a step forward.

The other point is to make headers more self-documenting.  I see a 
missing parameter name in a declaration as missing essential 
information, and I don't want to see that in headers for code I am 
writing or responsible for.  (The exception being when the parameter is 
not actually used, but exists for overloading or for compatibility with 
specific function types - in which case it is good that it is unnamed.)

(This is just what /I/ want - I know other people might want different 
things.)