RTTI portability

[Martin von Loewis]

> > A) a user program derives from abi::pointer_type_info and then attempts
> > to use objects of that class within the type_info system?
> >
> > B) parts of the program other than those in libcxa.so attempt to use
> > the implentation defined entry points?
> 
> I am concerned about both.

Why is that a concern? If a user inherits from abi::pointer_type_info,
what undesirable effects could come out of that?

I was more concerned about having the compiler-provided code in a
static library which then gets integrated into somebody's shared
library (as gcc's libgcc.a gets integrated into every shared library,
likewise libCrun.a and libCstd.a of Sun CC).

> That solution implies a statement that the non-Standard-defined parts
> of the hierarchy are not available to users.  Fine with me, but someone
> wanted to make the field names in the hierarchy normative, which has no
> point unless they expected them to be used outside the target
> runtime.

Used in the sense of being accessed - yes, why not? However, I would
not expect users ever to create typeinfo objects.

> It is a traditional part of the SysV ABI that libc is _always_ a DSO.
> I presume that we're extending that assumption to libcxa, though I
> guess we'd better say so.

If that is the intent then yes - we should say that.

> I personally believe that anyone who links the system libraries into
> their program is tying his program to a particular implementation, and
> had better use only pieces from that implementation (if it's supported
> at all, which I wouldn't, and SGI traditionally hasn't).  So, ... no
> problem.

The problem is that there is a difference between system libraries and
the C++ runtime library - those typically come with the C++ compiler,
not (necessarily) with the system.

Regards,
Martin