vtbl layout

[Colin McCormack <colin at field dot medicine dot adelaide dot edu dot au>]

This is from gxxint.texi:

>WRITABLE_VTABLES
>This is a option that can be defined when building the compiler, that
>will cause the compiler to output vtables into the data segment so that
>the vtables maybe written.  This is undefined by default, because
>normally the vtables should be unwritable.

>People that implement object
>I/O facilities may, or people that want to change the dynamic type of
>objects may want to have the vtables writable.  Another way of achieving
>this would be to make a copy of the vtable into writable memory, but the
>drawback there is that that method only changes the type for one object.

Now, as it happens (http://field.medicine.adelaide.edu.au/coldstore) I
fall into that former category of people who implement object I/O
facilities.

We currently use this->_vptr to copy the vtbl, but we have to guess
about the size of the table, and we don't know anything much about its
layout.  I claim that this isn't necessarily a good thing.

Now, I know it's non-portable to rely upon vtbl's existence, let alone
its layout or any given means of discovering it, because such things
aren't defined as part of the language.  I would contend that the
language isn't capable of supporting the desired functionality in a
portable manner, that the functionality is worthwhile, and that
therefore this is a case in which non-portable code is acceptable.

In this context, I'm prepared to accept the liability in:

http://www.cygnus.com/ml/egcs/1998-Dec/0947.html
>If you consider it 100% likely, you will be able to write portable
>code and not get burned.  The second you start guessing and assuming
>things about the vtable layout, you will get burned.  You can write
>non-portable code, if you wish, you assume the responsibility and
>liability.

So, is there anywhere apart from the code itself where this layout is
documented?

Colin.