Return-Path: 
 <stdcxx-dev-return-5943-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org
Received: (qmail 47677 invoked from network); 2 Nov 2007 16:40:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 2 Nov 2007 16:40:03 -0000
Received: (qmail 96979 invoked by uid 500); 2 Nov 2007 16:39:51 -0000
Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org
Received: (qmail 96969 invoked by uid 500); 2 Nov 2007 16:39:51 -0000
Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:stdcxx-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:stdcxx-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:stdcxx-dev@incubator.apache.org>
List-Id: <stdcxx-dev.incubator.apache.org>
Reply-To: stdcxx-dev@incubator.apache.org
Delivered-To: mailing list stdcxx-dev@incubator.apache.org
Received: (qmail 96958 invoked by uid 99); 2 Nov 2007 16:39:51 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2007 09:39:51 -0700
X-ASF-Spam-Status: No, hits=2.6 required=10.0
	tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2007 16:40:13 +0000
Received: from isper.nabble.com ([192.168.236.156])
	by kuber.nabble.com with esmtp (Exim 4.63)
	(envelope-from <lists@nabble.com>)
	id 1InzYS-0007dU-RU
	for stdcxx-dev@incubator.apache.org; Fri, 02 Nov 2007 09:39:32 -0700
Message-ID: <13551223.post@talk.nabble.com>
Date: Fri, 2 Nov 2007 09:39:32 -0700 (PDT)
From: Travis Vitek <vitek@roguewave.com>
To: stdcxx-dev@incubator.apache.org
Subject: 19.exceptions.mt.cpp fails on AIX
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: vitek@roguewave.com
X-Virus-Checked: Checked by ClamAV on apache.org



I'm working on fixing an issue with test 19.exceptions.mt.cpp on AIX. The
issue is that the test spins in a loop because the loop counter is being
thrashed when an exception is copied onto the stack. Here is a simple
testcase.

#include <exception> 

void test_single_exception ()
{
    for (int i = 0; i < 5; ++i) {

        try {
            throw std::exception ();
        }
        catch (std::exception ex) {
            &ex;
        }

    }
}

int main ()
{
    test_single_exception ();
    return 0;
}

So the issue is actually not that complicated. The exception type provided
by STDCXX is 4 bytes in size, and the native one is 8. In and of itself,
that shouldn't really be a problem because the two definitions should never
coexist, right? So the problem really shows up when the config tests run,
they set the following macros...

#define _RWSTD_NO_EXCEPTION_ASSIGNMENT
// #define _RWSTD_NO_EXCEPTION_COPY_CTOR
#define _RWSTD_NO_EXCEPTION_DEFAULT_CTOR
#define _RWSTD_NO_EXCEPTION_DTOR
#define _RWSTD_NO_EXCEPTION_WHAT

If I'm reading the code correctly, this means that STDCXX will provide
definitions for the default ctor, copy-assignment operator, dtor and what().
The definition of the copy-ctor will come from somewhere else [where?].
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.

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, or should we provide our own definition of the copy
ctor, possibly looking at the compiler test to verify it is not wrong. Both
seem to work quite well, but I'm afraid I don't understand why we opt to use
the definitions of the 'special' functions that are provided. I guess I
would understand if I had got a linker error complaining of mulitply defined
symbols, but I don't.

Travis

-- 
View this message in context: http://www.nabble.com/19.exceptions.mt.cpp-fails-on-AIX-tf4738595.html#a13551223
Sent from the stdcxx-dev mailing list archive at Nabble.com.