Re: c++/5338: -pedantic reports ambiguous base

[Craig Rodrigues <rodrigc at mediaone dot net>]

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

From: Craig Rodrigues <rodrigc@mediaone.net>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, martind@bluearc.com,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/5338: -pedantic reports ambiguous base
Date: Thu, 24 Jan 2002 00:05:50 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5338
 
 Information incorrectly filed in PR 5349, now moved to PR 5338.
 ============================================================================
  Martin,
  
  Thanks for looking at this.
  
  10.1.4 has this example, which it claims is legal (incidentally my g++-3.0
  -pedantic agrees):
  
  struct L { int next; };
  struct A : L {};
  struct B : L {};
  struct C : A, B { void f (); };
  void C::f () { A::next = B::next; }
  
  If your previous transformation were also applicable here, this would be
  equivalent to "this->L::next = this->L::next;" - which is clearly not
  well-formed.  Have I missed some relevant distinction in the Standard
  between data member lookup and member function lookup?
  
  While the Standard paragraph isn't exactly clear, I don't think that the
  members of the set that is constructed under 10.2.2 can be of the form
  "HwQueue's void pop() member".  Rather, they have to include information
  about which subobject they involve.  In this way, the set produced by a
  lookup for undecorated "pop();" would be:
  
  { "direct base class ISImq's direct base class HwQueue's void pop()",
    "direct base class ISPmq's direct base class HwQueue's void pop()"}
  
  Which isn't a singleton set, and so the program wouldn't be well-formed.
  
  This all hinges on "name lookup begins in the scope of the
  nested-name-specifier" implying something like "name lookup does not
  consider sub-objects outside the scope of the nested-name-specifier".
  
  Cheers,
  
  -----Original Message-----
  From: Martin v. Loewis [mailto:martin@v.loewis.de]
  Sent: Thursday, January 10, 2002 12:15 AM
  To: martind@bluearc.com
  Cc: gcc-gnats@gcc.gnu.org; debian-gcc@lists.debian.org
  Subject: Re: -pedantic reports ambiguous base
  
  
  > Without -pedantic there is not even a warning (even with -W -Wall).
  
  > 10.2.1 says "for a qualified-id, name lookup begins in the scope of
  > 10.2.the nested-name-specifier".  In which scope, I don't think the
  > 10.2.reference to pop() or HWQueue, for that matter, is ambiguous.
  
  This is caused by the fragment in cp/init.c
  
    /* Convert 'this' to the specified type to disambiguate conversion
       to the function's context.  Apparently Standard C++ says that we
       shouldn't do this.  */
    if (decl == current_class_ref
        && ! pedantic
        && ACCESSIBLY_UNIQUELY_DERIVED_P (type, current_class_type))
  
  It seems there are several interpretations of 10.2/1. GCC's
  interpretation is that, indeed, lookup starts in ISPmq, and finds
  HwQueue::pop. So the call you have written is equivalent to
  
    this->HwQueue::pop();
  
  which is ambiguous.
  
  It would be good if you could achieve independent clarification,
  e.g. through comp.std.c++. If people are of different opinion there as
  well, consider filing a Defect Report. Notice that variations of this
  have been discussed repeatedly in comp.stdc.c++; you may want to read
  the archives.
  
  Regards,
  Martin
  
  
  *********************************************************************
  This e-mail and any attachment is confidential. It may only be read, 
 copied and used by the intended recipient(s). If you are not the 
 intended recipient(s), you may not copy, use, distribute, forward, store 
 or disclose this e-mail or any attachment. If y ou are not the intended 
 recipient(s) or have otherwise received this e-mail in error, you should 
 destroy it and any attachment and notify the sender by reply e-mail or 
 send a message to sysadmin@bluearc.com
  *********************************************************************