🚀 go-pugleaf

I apologize if 100 people already reported this one before me.  It
*has not* been fixed with gcc-2.3.1!  I haven't received any
acknowledgment, either.

The program
--------8<--------
#include <stream.h>

class P {
public:
  virtual void hello() { cout << "hello\n"; }
  void callhello() { hello(); }
};

class C : public P {
public:
  virtual void hello() { cout << "hullo\n"; }
};

void g(P x) { x.callhello(); }	// should call P::hello()

int main() {
  C z;
  z.hello();			// correctly calls C::hello()
  g(z);				// erroneously calls C::hello()
}
--------8<--------
produces the erroneous output
	hullo
	hullo
instead of
	hullo
	hello

This is incorrect, since the x is a value parameter, whence
dispatching should be static.  This occurs for compilation without
flags, with -g, -O, or both.

System info: SparcStation ELC, SunOS 4.1.2

Compiler info: g++ 2.2.2, libg++ 2.2, no modifications

# GCC was configured as follows:
./configure --target=sparc-sun-sunos4.2 [I had typed 4.2 instead of 4.1.2 ;-]

I already posted a request for comments to gnu.g++.help and enclosed
some responses below.

Thank you for your cooperation,

-Konstantin [laufer@math.luc.edu]

> Date:    16 Oct 92 22:24:22 GMT
> From:    jbuck@forney.berkeley.edu (Joe Buck)
> Newsgroups: gnu.g++.help
> Subject: Re: Dispatching bug in g++?
> 
> In article <1992Oct16.204850.3311@lucpum.it.luc.edu> laufer@math.luc.edu
> submits the program
> [...]
> and writes:
> 
> This looks like a fundamental bug in the default copy constructors
> generated by g++ (determined by looking at the assembly language output).
> They copy everything, including the pointer to the virtual function table.
> This is wrong; the first word of the destination object should always be
> the virtual function table for that object, regardless of what is copied
> into it.
> 
> That is, when z is passed by value, its virtual function table pointer
> is copied into x, the formal parameter for g(P), so that x is not
> really a P at all, but rather a C.
>
> --
> Joe Buck	jbuck@ohm.berkeley.edu

> Date:    19 Oct 92 08:47:32
> From:    eb@ascent.com (Ed Barton)
> Newsgroups: gnu.g++.help
> Subject: Re: Dispatching bug in g++?
> 
> In article <7313@transfer.stratus.com> lee@deneb.sw.stratus.com (Lee Cooprider)
>  writes:
> 
>    >void g(P x) { x.callhello(); }	// should call P::hello()
> 
>    I'm having trouble understanding why this is a bug; it looks like the exact
>    behavior that virtual functions are supposed to provide.  Reference manual
>    section r.10.2 states "a call of 'vf' for an object of class D invokes D:vf
>    (even if access is through a pointer or reference to P)".
>    ...
>    Am I missing something about this program that makes my analysis wrong?
> 
> Yes, here is what you are missing: The argument x here is not a
> pointer or reference.  It is declared as an actual object, of type
> exactly P and not any subclass of P, to be passed by value and not
> reference from any caller of the function.  For instance, because P is
> declared as an actual new object, it won't have space for any
> additional slots referenced by the virtual functions that will
> erroneously be called, and referencing those slots will lead to
> disaster.