Travis Vitek wrote:
Martin Sebor wrote:
That said, what is the appropriate solution? Should we just pad the type
out
to the correct size,
Yes. As Farid says, the XLC exception and ours must have the same
size.
Is this a binary compatible change? I've always believed changing the size
of a type breaks binary compatibility, but if the the special functions are
no-op, I'm thinking it might be safe.
No, it's not binary compatible, and neither is the status quo
(i.e., stdcxx 4.2.0 and most likely all previous versions of
stdcxx on AIX) is binary incompatible with the AIX runtime.
The only reason why I suspect no one has noticed it yet is
most likely because runtime exceptions are relatively rare
and perhaps also because the context where the stack
corruption occurs is either benign, recoverable, or gets
chalked up to cosmic rays.
I was going to go on and say that the incompatibility caused
by the fix won't be detectable because it simply fixes an
already existing incompatibility (with the runtime) when I
realized that there are many more (user-defined) exception
classes that are unrelated to the runtime exceptions. So by
fixing the incompatibility with the runtime we will be
breaking compatibility with user-defined classes...
Martin Sebor wrote:
I guess I
would understand if I had got a linker error complaining of mulitply
defined
symbols, but I don't.
This (the interface between the language runtime and the library)
is the most difficult area of the library for independent library
authors like us to get right. We can't help but make assumptions
about the runtime. Some are based on our inspection of the native
library headers (which may change in subtle but sometimes
important ways from one release to another), others we try to
automate (the detection of the special member functions of the
exception classes). Both approaches are fraught with peril.
Okay. So the appropriate solution is to modify the exception header to have
the correct size. As I mentioned, I think I can easily write a config test
to determine the necessary pad and apply it. Is that a better approach?
You mean as opposed to conditionally hardcoding it for XLC?
I'm not sure it's worth the trouble, although the information
would be useful in the test suite to verify that our size is
the same as the runtime classes.
At the very least I'd like to determine the size of the runtime library
version of std::exception and then add a test that will check the size
matches up with the size of the type we are providing. That way we have a
way to be notified of the problem in the future instead of having to find it
the hard way.
That's a good idea. In fact, I think there is a need for a class
of tests (configuration and/or otherwise) that are *required* to
pass in order to put out a release. Otherwise, unless we implement
a no-test-failures policy, we will risk putting out badly broken
releases.
Martin
