From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6252 invoked by alias); 10 Mar 2019 12:05:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6244 invoked by uid 89); 10 Mar 2019 12:05:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=sk:wmissin, sk:Wmissin, H*f:sk:f8c66f7, Starynkevitch X-HELO: relay11.mail.gandi.net Received: from relay11.mail.gandi.net (HELO relay11.mail.gandi.net) (217.70.178.231) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 10 Mar 2019 12:05:13 +0000 Received: from [192.168.1.10] (lstlambert-656-1-266-187.w193-248.abo.wanadoo.fr [193.248.54.187]) (Authenticated sender: basile@starynkevitch.net) by relay11.mail.gandi.net (Postfix) with ESMTPSA id EE0C8100004; Sun, 10 Mar 2019 12:05:07 +0000 (UTC) Subject: Re: Warning for C Parameter Name Mismatch To: David Brown , gcc@gcc.gnu.org Cc: Joel Sherrill References: <1552168709.15796.ezmlm@gcc.gnu.org> <7fdc8d4f-6c32-5354-936a-be53e1dac521@hesbynett.no> From: Basile Starynkevitch Message-ID: Date: Sun, 10 Mar 2019 12:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <7fdc8d4f-6c32-5354-936a-be53e1dac521@hesbynett.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-03/txt/msg00072.txt.bz2 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: >> >>> >>> 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. > 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