This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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: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.On Fri, 8 Mar 2019, Joel Sherrill wrote:I think this would be normal and expected - an installed header would use a reserved-namespace name for the parameter while the implementation usesCan 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) {...}a non-reserved name that's more convenient for use within theimplementation. (Thus anything like this would only be useful if it canknow 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.You could avoid that warning by avoid naming the parameters in your header files, so you would declareint 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |