Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <472B9BB3.9090109@roguewave.com>
Date: Fri, 02 Nov 2007 15:50:43 -0600
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.5
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: 19.exceptions.mt.cpp fails on AIX
References: <13551223.post@talk.nabble.com> <472B77AB.7000506@roguewave.com>
 <13556315.post@talk.nabble.com>
In-Reply-To: <13556315.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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