Re: Attribute questions

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Fri, 29 Jun 2001, Mark Mitchell wrote:

> I don't care about the order thing, but I agree with your other comment.
> 
> The new C++ parser is taking a more consistent approach to this, and
> is combining all the attributes together before letting the rest
> of the compiler know about them, so it should just work. Someday
> it will be the new C parser too...

In the course of fixing this for the C front end and common code - and 
fixing the places in the C++ front end that need changing for changed 
interfaces to common code, without generally making the change in the C++ 
front end - I came across an oddity in the C++ front end's handling of 
attributes on nested declarators (which has never really worked, execpt 
maybe for some machine attributes, because the common code in 
decl_attributes lacks the necessary support).  The C++ version of 
grokdeclarator does

        case TREE_LIST:
          {
            /* We encode a declarator with embedded attributes using
               a TREE_LIST.  The attributes apply to the declarator
               directly inside them, so we have to skip an iteration
               before applying them to the type.  If the declarator just
               inside is the declarator-id, we apply the attrs to the
               decl itself.  */
            inner_attrs = TREE_PURPOSE (declarator);
            ignore_attrs = 1;
            declarator = TREE_VALUE (declarator);
          }
          break;

I don't think this skipping an iteration is correct.  For example, given

	int ***__attribute__((foo)) *x;

(which should clearly mean "pointer to foo-attributed pointer to pointer
to pointer to int, simply by analogy with const), the debugger shows that
decl_attributes is being passed the type "int****" to which it is asked to
apply the attribute "foo", when it should be passed "int***".

This change (revision 1.240 of decl.c, by Jason Merrill) was apparently 
for

  int (__cdecl * __cdecl f ())();

which (according to the documentation I wrote - none was added by that 
patch) means

  function returning cdecl pointer to cdecl function returning int

I guess the patch was meant to make it mean

  cdecl function returning pointer to cdecl function returning int

which my grammar in "Attribute Syntax" would make be the meaning of

  int (__cdecl * (__cdecl f) ())();

but unless variant documentation can be provided explaining the formal
syntax intended by that 1998-10-18 patch - especially as I think the
current C++ parser (as far as I can understand it) follows my parse
(function declarator as the innermost), then grokdeclarator breaks it - I
must suspect that my documentation rather than the C++ front end is
correct here, and implement what I've documented for C.

-- 
Joseph S. Myers
jsm28@cam.ac.uk