[cfe-dev] Access specifiers and anonymous unions

Abramo Bagnara abramo.bagnara at gmail.com
Fri May 28 10:46:03 PDT 2010


Il 28/05/2010 19:25, John McCall ha scritto:
> On May 28, 2010, at 9:00 AM, Abramo Bagnara wrote:
>> I might imagine this is done
>> for access checking, but as I'd guess that access checking is done
>> traversing and checking *all* the nesting records (also anonymous ones)
>> the union fields would be unaccessible from outside class S also if
>> correctly marked as public.
> 
> Your guess is wrong;  we assume that the decl's access specifier correctly
> describes the access of the member when considered as a member of its
> declaring class.  There is no value in remembering the access of the decl
> within the anonymous union, first, because it is impossible to access
> anything from the context of the anonymous union (as opposed to
> from its enclosing context) after it is parsed, and second, because
> (as you've rightly observed) that access is always public.

I'm not sure to understand the difference you see between

class s {
  struct {
    int a;
    int b;
  };
};

and

class q {
  struct {
    int a;
    int b;
  } c;
};

and why you treat the former as a special case, but that apart it's not
a problem in either way once there is the possibility to know access
specifier written in source.

> Is there a value to remembering the original access specifier, i.e. public,
> that I'm not seeing?  I would much prefer not to change the current behavior,
> but we could certainly provide a method that reports the "direct" access
> specifier, i.e. public if the DC is an anonymous struct or union.

The value is for pretty printer like applications and for source
checkers. However to add an AccessSpecifierAsWritten flag inside the
decl is not the ideal solution, it can't represent something like this:

class s {
private:
  int a;
};

(undistiguishable from class s { int a; })

or

class s {
public:
private:
  int a;
};

To represent correctly the above we might decide to have a node for
access specifiers at the same level of other decls.




More information about the cfe-dev mailing list