__attribute__((unused)) and parameter decls

[Nathan Sidwell]

G++ goesn't grok __attribute__ when applied to function parameters. The
rational being that C++ allows an unnamed parameter to mean the
parameter is unused. -- Actually the documentation on
__attribute__((unuesed)) talks about functions 

extend.texi::1492 says,
@item unused
This attribute, attached to a function, means that the function is meant
to be possibly unused.  GNU CC will not produce a warning for this
function.  GNU C++ does not currently support this attribute as
definitions without parameters are valid in C++.

I guess this should be amended to say 'object' or 'identifier' or
something.

Anyhow, __attribute__((unused)) says 'this might not be used', not 'this
is not used' (as the recent discussion here has elaborated), and so it's
different to the C++ meaning of an unnamed parameter (which obviously
isn't used).

So my request is, can g++ be extended so that __attribute__((unused))
works on parameters? That'd remove an exception to the extension, and
help me use it in a consistent manner across both gnu C and gnu C++.
It'd also allow parsing of C header files which use this extension.

Here's a test file showing what I mean
--begin attrunused.ii
void fn(int arg1, int arg2 __attribute__((__unused__)))
{
  return;
}
extern "C" void fn2(int arg1, int arg2 __attribute__((__unused__)));
--end attrunused.ii

Looking at cp/parse.y and comparing with c-parse.y, it looks to me that
the BNF for `parm' at line 3567 would be extended with a
`maybe-attribute' non-terminal. Or is it more complicated and the
named_parm and type_id non-terminals need expanding?

Is it something that I could/should have a go at (not knowing much about
the tree_lists of g++, but understanding BNF, bison and that stuff).
(i.e. Is this something one of the experts is actually liable to do in
five minutes whilst I'm flumoxing around trying to figure things out.)

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk