Re: C++ PATCH: ABI bug for vcall offsets

[Michael Matz <matz at suse dot de>]

Hi,

On Thu, 7 Nov 2002, Mark Mitchell wrote:

>   struct A {
>     virtual void a ();
>   };
>
>   struct B : virtual public A {
>     virtual void b ();
>     virtual void a ();
>   };
>
>   struct C {
>     virtual void c ();
>   };
>
>   struct D : public C, public B {
>   };
>
>   struct E : virtual public D {
>     void b ();
>   };
>
>   void E::b () {}
>
> The issue is the order of the vcall offsets for B in D's vtable; do
> you put b first or a first?  We were putting a first because A is B's
> primary base, but the ABI says you use declaration order.  That often
> doesn't bite you because you recurse into A to lay out its vtable, but
> that doesn't happen when B is a non-primary base of the eventual
> virtual base (D, in this case).

Excuse an uninformed question.  But does that mean, that it now is
possible that one accidentially breaks binary compatibility when adding
virtual functions (or overwriting them) and accidentially swapping some
decls?  Like for instance when version 1 had:

struct A {
  virtual void a() {do_nothing();}
};

struct B : virtual public A {
  virtual void b() {do_b_v1();}
};

and in version 2 I overwrite B::a, but accidentially declare b() and a()
in different order:

struct B : virtual public A {
  virtual void b() {do_b_v1();}
  virtual void a() {do_a_v2();}
};

I guess that needs a more involved example like yours to become wrong, but
if it somewhen does I wonder why the ABI was defined this way.


Ciao,
Michael.