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-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.
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.
