On Sat, 9 Mar 2019, 02:23 Eric Gallager, <eg...@gwmail.gwu.edu> wrote:
> On 3/8/19, David Brown <david.br...@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) {...}
>
I don't think that's valid in C, only C++, and I would expect no warning
for such cases. But I don't see much value in the suggested warning at all.
