c++/7522: access by friend function's default argument

c++/7522: access by friend function's default argument

[Christoph Ludwig]

>Number:         7522
>Category:       c++
>Synopsis:       access by friend function's default argument
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 07 05:46:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de>
>Release:        gcc version 3.1
>Organization:
>Environment:
Linux 2.4.10-4GB i686 (SuSE 7.3)
>Description:
g++ 3.1 rejects access to a private class member by the
default argument of a friend function.

But clause 11, paragraph 7, of the C++ standard seems to
allow the access.

g++ -v gives the following:
  Reading specs from /home/lidiaadm/gcc-3.1/gcc-3.1/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
  Configured with: ./configure --prefix=/home/lidiaadm/gcc-3.1/gcc-3.1 --enable-threads=posix --enable-languages=c,c++
  Thread model: posix
  gcc version 3.1

gcc 3.0.3 and 2.95.3 (Linux/i) as well as 2.95.2 
(Solaris 8 / UltraSparc) show the same behaviour.

Regards

Christoph Ludwig
>How-To-Repeat:
g++ -c friend_default.cc
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="friend_default.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="friend_default.cc"

Y2xhc3MgQSB7CnByaXZhdGU6CiAgICBzdGF0aWMgY29uc3QgaW50IGRhdGE7CiAgICAKICAgIGZy
aWVuZCBpbnQgZihpbnQpOwp9OwoKY29uc3QgaW50IEE6OmRhdGEgPSA1OwoKaW50IGYoaW50IGQg
PSBBOjpkYXRhKSB7Cn0KCg==

Re: c++/7522: access by friend function's default argument

[bangerth]

Synopsis: access by friend function's default argument

State-Changed-From-To: analyzed->closed
State-Changed-By: bangerth
State-Changed-When: Tue Jan 28 16:58:47 2003
State-Changed-Why:
    Works with 3.4, probably thanks to one of Kriang's patches.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7522

Re: c++/7522: access by friend function's default argument

[Christoph Ludwig]

The following reply was made to PR c++/7522; it has been noted by GNATS.

From: Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/7522: access by friend function's default argument
Date: Fri, 17 Jan 2003 09:37:57 +0100

 Hi,
 
 On Thu, Oct 31, 2002 at 05:24:55PM -0000, bangerth@dealii.org wrote:
 > Synopsis: access by friend function's default argument
 > 
 > State-Changed-From-To: feedback->analyzed
 > State-Changed-By: bangerth
 > State-Changed-When: Thu Oct 31 09:24:55 2002
 > State-Changed-Why:
 >     One way or other, the example Christoph gave shows a bug,
 >     since treatment is not consistent. So I reset the state
 >     to "analyzed".
 >     
 >     And no, I don't know what is right and wrong here, sorry.
 
 A post by John Spicer to comp.std.c++ (Thread: "Req Clarification:
 private type used in parameter list of friend function") pointed me to
 11.0.5 in the standard. There is an example that settles the question,
 I think:
 
   class A {
     typedef int I; // private member
     I f();
     friend I g(I);
     static I x;
   }; 
 
   A::I A::f() { return 0; } 
   A::I g(A::I p = A::x); 
 
 gcc 3.2.1 rejects the default argument in the last line, but according
 to the standard the example is well formed.
 
 Regards
 
 Christoph
 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7522
 
 

Re: c++/7522: access by friend function's default argument

[bangerth]

Synopsis: access by friend function's default argument

State-Changed-From-To: feedback->analyzed
State-Changed-By: bangerth
State-Changed-When: Thu Oct 31 09:24:55 2002
State-Changed-Why:
    One way or other, the example Christoph gave shows a bug,
    since treatment is not consistent. So I reset the state
    to "analyzed".
    
    And no, I don't know what is right and wrong here, sorry.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7522

Re: c++/7522: access by friend function's default argument

[Christoph Ludwig]

The following reply was made to PR c++/7522; it has been noted by GNATS.

From: Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
	nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/7522: access by friend function's default argument
Date: Thu, 31 Oct 2002 17:43:00 +0100

 On Wed, Oct 30, 2002 at 11:32:04PM -0000, bangerth@dealii.org wrote:
 > Synopsis: access by friend function's default argument
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Wed Oct 30 15:32:03 2002
 > State-Changed-Why:
 >     I don't think this is a bug. 11.0.7 states:
 >     7 The  names  in  a  default argument expression (_dcl.fct.default_) are
 >       bound at the point of declaration, and access is checked at that point
 >       rather than at any points of use of the default argument expression.
 >     
 >     I don't see anything right away in the standard that for
 >     checking access to the names used in the default value has
 >     to happen inside the scope of the function that uses them,
 >     but common reasoning would suggest that the enclosing scope
 >     is used, in which case the befriended function is not
 >     taken into account.
 >     
 >     I'll put this report into feedback mode. Please let us know
 >     if you can follow my reasoning, or whether we shall reopen
 >     the report.
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7522
 
 I admit I am not totally sure about this. Prior to submitting the PR,
 I asked for clarification in comp.lang.c++.moderated and
 comp.std.c++, but whithout success.
 
 The reference to 11.0.7 does not totally convince me; as I read it,
 the default argument expression has to undergo the same access checks
 as any other name bound in the parameter list of the function
 declaration. When I prepared an example I found g++ 3.2 seems to apply
 the rules inconsistently. Please consider:
 
  class A {
  private:
      class AInner {
      public:
          AInner(int i);
      };
 
      static const AInner ai;
      friend void f1(const A::AInner& x);
      friend void f2(const A::AInner& x);
      friend void f3(const A::AInner& x);
  };
 
  const A::AInner A::ai(5);
 
  void f1(const A::AInner& x);                  // ok
  void f2(const A::AInner& x = A::AInner(5));   // ok
  void f3(const A::AInner& x = A::ai);          // error
 
 
 If I follow your reasoning, then all three function declarations
 should be flagged as erroneous, I think. But g++ 3.2 complains about
 the last declaration only. 
 
 Even if I conceded that only the default argument expressions in this
 example should be checked at namespace scope for access violations:
 Why should the constructor of the private member class A::AInner be
 accessible, but not the private static member variable A::ai?
 
 For what it is worth, Comeau 4.3 accepts the above code.
 
 Regards
 
 Christoph
 
 -- 
 http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
 LiDIA-CA: http://www.informatik.tu-darmstadt.de/TI/Forschung/LiDIA-CA/
 

Re: c++/7522: access by friend function's default argument

[bangerth]

Synopsis: access by friend function's default argument

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Wed Oct 30 15:32:03 2002
State-Changed-Why:
    I don't think this is a bug. 11.0.7 states:
    7 The  names  in  a  default argument expression (_dcl.fct.default_) are
      bound at the point of declaration, and access is checked at that point
      rather than at any points of use of the default argument expression.
    
    I don't see anything right away in the standard that for
    checking access to the names used in the default value has
    to happen inside the scope of the function that uses them,
    but common reasoning would suggest that the enclosing scope
    is used, in which case the befriended function is not
    taken into account.
    
    I'll put this report into feedback mode. Please let us know
    if you can follow my reasoning, or whether we shall reopen
    the report.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7522