Re: Warning for C Parameter Name Mismatch
On Sat, 9 Mar 2019, 02:23 Eric Gallager, wrote:
> On 3/8/19, David Brown 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.
Re: Warning for C Parameter Name Mismatch
On 09/03/2019 03:23, Eric Gallager wrote:
On 3/8/19, David Brown 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.)
Re: Warning for C Parameter Name Mismatch
On Sat, Mar 09, 2019 at 08:30:19AM +, Jonathan Wakely wrote:
> On Sat, 9 Mar 2019, 02:23 Eric Gallager, wrote:
> > 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.
This is perfectly fine C. Parameter names are optional in prototypes.
It's different if it is the function definition, I think that is what
you mean?
Segher
Re: Warning for C Parameter Name Mismatch
On Sat, Mar 9, 2019, 11:27 AM Segher Boessenkool
wrote:
> On Sat, Mar 09, 2019 at 08:30:19AM +, Jonathan Wakely wrote:
> > On Sat, 9 Mar 2019, 02:23 Eric Gallager, wrote:
> > > 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.
>
> This is perfectly fine C. Parameter names are optional in prototypes.
> It's different if it is the function definition, I think that is what
> you mean?
>
That's how I read it and that would not be a warning IMO.
Back to a point in my original email that seems to have been missed.
Doxygen reports this as a warning. I would just like the option to find it
with gcc as well.
And not checking system headers is reasonable in general. For RTEMS though,
we are implementing those system headers and do follow the names in the
standards for parameter names in the implementation.
--joel
>
>
> Segher
>
合C法R经f营W
办QO 理 $ +Q+V+信/- -- & $ -- I 3 4 髮 $--- 2 4 3 4 & $ ---6 1 4 8 漂 $ -2019/3/10
Re: Warning for C Parameter Name Mismatch
(I am reading the GCC mailing list in digest mode)
On 3/9/19 10:58 PM, gcc-digest-h...@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.
--
Basile STARYNKEVITCH == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France
