On May 23, 2013, at 2:36 AM, Ismail Pazarbasi <[email protected]> wrote: > PR9103 is concerning access to a static protected member of a base class > member from a friend function body defined in derived class. > > PR11515 is concerning accessing a private member of another class that is > befriending class of a friend function. > > The patch for PR9103 used lexical context of the befriended class for > checking access from a friend function definition. Per standard, a friend > function is in the lexical scope of the class iff it's defined in the class. > Using lexical scope of friend function as its declcontext for access checking > leads to PR11515. > > I think EffectiveContext should not consider lexical scope of friend function > as declcontext. Access to protected static members of a base class should be > handled differently.
I think your patch isn't quite right and would be clarified by being more specific about how exactly we're interpreting the language rule. The standard says that members that are protected as named in a class N should be accessible if there exists an enclosing context F which is a friend of a class C which is derived from N and in which a notional public member of N would be accessible (ignoring friendship) in C. We've decided to not implement this rule as stated in the standard, basically because the search for C is an unbounded search and has major problems with e.g. modules, template instantiation order, etc. We do, however, implement it for members to which the protected instance member restriction applies, because the instance context reasonably bounds the search for the befriending class. The right way to think about how PR9103 asks us to extend our interpretation is that we should also consider the lexical context as a potential bound on C. In the degenerate case from that PR, the immediate context is a friend function of the class C, but we can generalize this to say that we should perform searches bounded by any classes in the lexical context. However, we should not do this extended search when we have an instance context because it would potentially bypass the [class.protected] restriction. So I think what you should do is: 1. Go ahead and make the change where you don't collect lexical DCs when building the EffectiveContext. 2. Add to EffectiveContext a lazily-constructed set of lexically-enclosing classes. 3. In HasAccess, when you're working with a protected member and you don't have an instance context, search for friends starting from all the lexically-enclosing classes. 4. Change comments and variable names as appropriate to make it clear that we're talking about an arbitrary bounding context for the search, not specifically an instance context. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
