Travis Vitek wrote:
Farid Zaripov-2 wrote:
From: Travis Vitek [mailto:[EMAIL PROTECTED]
The definition of the copy-ctor will come from somewhere else
[where?].
The definition of the copy-ctor should be present in libc.
The C library has definitions for C++ types that are supposed to be part of
the C++ Standard Library? That just seems wrong. You must mean libC.a on AIX
[or more generally the C++ library]. In that case I don't think any symbols
should _ever_ come from there. We shouldn't be linking the C++ library at
all if we can avoid it.
None of this really explains why we don't always define all of the members
of std::exception ourselves. I guess if we absolutely cannot avoid getting
libC.a linked then we would see link errors complaining of multiply defined
symbols, but I don't see them if I modify the config header and rebuild.
libC.a contains other important runtime symbols that C++ programs
can't do without (e.g., exception handling, runtime type id info,
dynamic memory management, etc.) We use the xlCcore command to avoid
linking with the native C++ Standard Library. IBM implemented xlCcore
partly in response to our complaints about problems due to mixing the
native and our implementation of the C++ Standard Library in the same
program. You can view the history of the whole issue here (on the
inside of the Rogue Wave firewall):
http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=2352
From the issue you can see that we asked IBM to split up xlC.a into
two libraries like most other compiler vendors do: the C++ runtime
library and the rest of the C++ Standard Library. They decided to
do it their way and keep all symbols in the same library. I'm not
comfortable with the solution because it feels like magic to me and
makes me wonder if it even works, but unless we can point to actual
problems that it causes there's little we can do about it.
Martin
Farid Zaripov-2 wrote:
From: Travis Vitek [mailto:[EMAIL PROTECTED]
Anyways, an exception is created and copied out for the unwind. The
exception is then copied back onto the stack at the location
the exception
is handled. The code that actually copies the exception
expects the object
to be 8 bytes in size, but the code that created the exception only
allocates 4 bytes for it.
The definitions of the std::exception class in STDCXX and AIX system
headers should be the same. If no, the include/exception header file
should have corresponding #ifdef _RWSTD_OS_AIX / #endif
Technically that will break binary compatibility, right? I realize the
STDCXX 'special' functions are all implemented as no-ops, but there is
probably some contrived user-code that would break because of this change.
If this change is indeed safe [I'm having trouble coming up with a testcase
that will break because of it], then why don't we create a compiler test to
determine if the exception class has has any pad so that we can pad out the
declaration of std::exception. That way we would be able to conveniently
avoid this problem in the future.
Farid Zaripov-2 wrote:
From: Travis Vitek [mailto:[EMAIL PROTECTED]
So here is my problem with all of this. How is this safe? If
the one of the 'special' functions provided by the system has
some side effect, and we use that implementation, then how
can we safely define any of the other 'special' functions?
That said, what is the appropriate solution? Should we just
pad the type out to the correct size
Yes, since the stdcxx uses std::exception class just as base class
for the other exception classes (the members of the std::exception are
not used).
Farid.
I think the members of std::exception provided by stdcxx are actually being
used when they are provided, but their definitions are 'dumb'.
Travis
