Re: Warning for C Parameter Name Mismatch

[David Brown]

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.

Re: Warning for C Parameter Name Mismatch

[Basile Starynkevitch]

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




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

GSoC

[Martin Emil]

Hello ,
I am Martin Emil last year computer engineering student from Egypt .
I came through your project in GSoC  and i am very interested about it and
want to work on it.
I have strong knowledge in C,C++,Java and python programming languages .
I am interested in *Implementation of OMPD

in
GCC idea  , and i want to know more about it .*
*I am seeking a mentor to work with on this idea*
Here is the link to my github page :
https://github.com/MartinEmilSaad

I am looking forward to hearing from you

gcc-9-20190310 is now available

[gccadmin]

Snapshot gcc-9-20190310 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/9-20190310/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 269561

You'll find:

 gcc-9-20190310.tar.xzComplete GCC

  SHA256=c08d516212beba122b86d31f128489227451cadb4c34ecf19cfead2315d26310
  SHA1=b4716f5ed921fe6529a154a5b4b94715372a7ff1

Diffs from 9-20190303 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.