From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15638 invoked by alias); 14 Jun 2013 13:13:03 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 15606 invoked by uid 48); 14 Jun 2013 13:12:58 -0000 From: "potswa at mac dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/57593] Friendship not extended into friend member-declaration Date: Fri, 14 Jun 2013 13:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: potswa at mac dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00729.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57593 --- Comment #2 from David Krauss --- The maintainer (Mike Miller at EDG) said simply that he will add it to the list, but as far as I know a number isn't assigned until the new list is drafted. The title is "access granted by friendship to class-scope friend declaration." (But I suppose he could take a liberty and remove the redunda= nt "class-scope".) Regardless of any possible defect, GCC is inconsistent. The change in access applies to certain declarations, not others, but GCC is applying it to part= s of certain declarations (seemingly only the function body is excluded). To be consistent with the current standard, the only choices are to allow all 3 examples or disallow all 3. The latter choice would be a nasty breaking cha= nge. If it helps, here is the text of DR submission. ---- Friendship is not transitive, but it does grant access to "member declarati= ons of the befriended class." ([class.friend]/2) And a friend is declared by a member-declaration. Is a grammatical member-declaration with the friend specifier still a member declaration? class c { class n {}; friend struct s; }; struct s { friend class c::n; // 1 friend c::n g(); // 2 friend void f() { c::n(); } // 3 }; If a friend member-declaration is not a member declaration, then it is impossible to grant access to a private nested class (1) or a function comp= osed from a type specified using a private nested class (2). Both GCC and Clang allow these examples. If a friend member-declaration is a member declaration, then it implements = one degree of transitive friendship, if it is also a definition (3). Clang acce= pts this example, but GCC rejects it. Friends are enough like members that the access should apply. One common application is operator<< . A manipulator proxy class may need access from = its insertion operator to its client's restricted members. Another application = is to define a function that would otherwise be a nonstatic member but receive= s a container or smart pointer, not a direct reference to the object. These are= the most common cases for the inline friend definition syntax. They are found by ADL so the namespace-scope declaration may be omitted. Working around by befriending the pseudo-member friend may be troublesome a= s it may violate separation of concerns, form undesired associated classes for A= DL, or require forming a declaration which may use inconvenient nested types or reduplicated SFINAE. Although access control isn't really a security mechanism, no "exploit" wou= ld be opened by granting access because a friend can always delegate to a stat= ic member anyway. Proposed resolution: Modify [class.friend]: =E2=80=A6 can be accessed in the base-specifiers, member-declarations, and = definitions of members of the befriended class. Is there any context within a class-specifier where access control is perfo= rmed besides its base-specifiers and member-declarations? It doesn't seem to app= ly to name lookup in the template-name of a partial or explicit specialization, but I can't find the spec. Perhaps it should be: =E2=80=A6 can be accessed in the class-specifier and definitions of members= of the befriended class. >>From gcc-bugs-return-424351-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 14 13:31:38 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 25116 invoked by alias); 14 Jun 2013 13:31:38 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 25075 invoked by uid 48); 14 Jun 2013 13:31:32 -0000 From: "paolo.carlini at oracle dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/57593] Friendship not extended into friend member-declaration Date: Fri, 14 Jun 2013 13:31:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: paolo.carlini at oracle dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00730.txt.bz2 Content-length: 331 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57593 --- Comment #3 from Paolo Carlini --- Ok. Please, when you have a number, send it here. In any case, I suppose we'd rather prefer to have a resolution in order to act, otherwise we are not sure in which way we want to resolve any inconsistency.