Member of virtual classes incorrectly accessed in methods with no objet specification

["Casteyde" <casteyjp at club-internet dot fr>]

Hello, here are what I think is a bug. Tested and reproduced both on Linux and W32 :

 

Win32 conf :

 

gcc 2.95 (mingw32 port)

gas 2.9.4 (mingw32 port)

Windows 95 OSR2 (K6, 32Mo)

No Options ("gcc bug.cpp")

 

Linux conf :

 

gcc 2.95

gas 2.9.1 (SuSE Linux 6.1)

SuSE Linux 6.1, kernel 2.2.10 (gcc 2.95 recompiled with -fno-strict-aliasing)

No Options ("gcc bug.C")

 

Description of the problem :

 

The members of a virtual base class are incorrectly accessed when I specify only a part of the

path in the inheritance graph (that is, "B::i" and not "B::A::i"). In fact, it seems that gcc assumes

that the object is in the derived class B so specified, and doesn't see that it is in the base class A.

If I give the object pointer explicitly, (with "this->B::"), the member is correctly accessed.

Under Linux, I got a SIGSEGV (once, not reproduced), so memory is really incorrectly accessed. 

 

There should be at least a warning, if my construct is incorrect (none even with -Wall)...

Nevertheless, this bug is not very important, since I see no application of partial specification of

inheritance path and I can use this pointer.

 

Source file :

 

#include <iostream.h>

 

class A
{ 

public :
     int i;
}; 

 

class B : virtual public A
{
}; 

 

class C : virtual public A
{
}; 

 

class D : public B, public C
{
public :
     int f(void);
     int g(void);
}; 

 

int D::f(void)
{
     return B::i;          // Doesn't work.
} 

 

int D::g(void)
{
     return this->B::i; // Works because there is "this->".
} 

 

D d;

 

int main(void)
{
    d.C::i=325;                    // Wroks because there is "d."
    cout << d.f() << endl;     // Does not work, as mentionned upper.
    cout << d.B::i << endl;   // Works with "d" specified.
    cout << d.g() << endl;    // Works fine ("this" is specified).
    // Therefore, B::i works only when the object is specified (with "this" in a method). 

    return 0;
}
 

Regards,

 

C. Casteyde