C++ exceptions in C [was: Re: CVS commit: src/external/bsd/atf/dist/atf-c++]

[Julio Merino <jmmv%NetBSD.org@localhost>]

Hi toolchainers,

[ Please CC me any replies ]

Can anyone that understands the C/C++ ABI provide some insight on the
change below?  I'm interested in knowing which behavior is right
(i386's or amd64's) or if this is behavior is just undefined.  In the
former case, I'll write a test case for the problem; in the latter,
I'll just ignore it :-P

Summarizing: what should happen when a C++ function calls a C function
that, in turn, calls another C++ function that throws exceptions?  Up
to where should exceptions propagate?  Intuition tells me that they
should never reach C land.  (Yeah, no comments on this bizarre
setup...)

Thanks!


On Tue, Jul 6, 2010 at 7:03 PM, Julio Merino <jmmv%netbsd.org@localhost> wrote:
> Module Name:    src
> Committed By:   jmmv
> Date:           Tue Jul  6 18:03:37 UTC 2010
>
> Modified Files:
>        src/external/bsd/atf/dist/atf-c++: tests.cpp
>
> Log Message:
> Pull up revision 3becdd597a7f5f996eeceebf06ac7f77aaa7c30c from upstream:
>
> Catch and report unhandled exceptions before they propagate to C land
>
> The C++ interface to run test cases goes like this:
>
>    1) C++ run function -> 2) C run function -> 3) C++ wrapper for
>    test case -> 4) test case head/body/cleanup
>
> The previous code caught and reported unhandled exceptions in 1).
> However, such approach does not seem to work everywhere.  It fails,
> for example, in NetBSD/i386 but works in NetBSD/amd64.  I am not sure
> which platform implementation is correct nor if there even _is_ a
> defined behavior.  No matter what, it feels wrong and clunky.
>
> Move the last-resort exception catching to happen in 3) so that
> exceptions don't propagate back to C.
>
> Fixes the test-programs/result_test:result_exception test case in
> NetBSD/i386 5.99.34.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.3 -r1.4 src/external/bsd/atf/dist/atf-c++/tests.cpp
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
>



-- 
Julio Merino