This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linux vs. libio


>>>>> "Ulrich" == Ulrich Drepper <drepper@cygnus.com> writes:

    Ulrich> This is still no reason to break compatibility.  If the
    Ulrich> virtual tables require a new layout one can add new ones.

OK, I'm listening.  I don't understand what you mean, but if you can
show me how to do this, and avoid having to have two separate libios
(one in libstdc++, and one in libc), I'll be all too happy to
implement it.

With the new ABI, pointers to virtual tables come at a different point
in the objects.  Bases are laid out in different orders.  There are no
longer pointers to virtual bases.  Some of that doesn't matter; some
of it does.  Given:

  struct _ios_fields { ... };
  class ios : public _ios_fields { ... };

it is no longer the case that you can cast an `ios *' to an
`_ios_fields *' without having to do modify the pointer value; the
vtable pointer comes before the _ios_fields object in an ios.

More importantly, the same holds for streambuf and _IO_FILE.  You
can't cast an _IO_FILE to a streambuf, or vice versa, without
modifying the pointer value.

That means the (old) macros (like JUMP1) that take an _IO_FILE *, go
find the vtable, and jump through it, don't work when given an
_IO_FILE * that came from a (new) streambuf; the vtable is now
*before* the _IO_FILE, not after.  Since there is code that uses those
macros already compiled into libc, I don't see how to make them
interoperate.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]