Re: exception from C function?

From:

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam>

Newsgroups:

microsoft.public.vc.language

Date:

Mon, 4 Feb 2008 12:39:33 -0600

Message-ID:

<OjkIxz1ZIHA.5984@TK2MSFTNGP06.phx.gbl>

"George" <George@discussions.microsoft.com> wrote in message
news:44E92988-971C-4733-A780-AAE53E939F3F@microsoft.com...

Thanks Ben,

As long as the throw and catch statements are in the same module, then a
C++
compiler has to make them work correctly or else it is not
standards-conforming.

I assume you mean we build .c and .cpp together into one DLL or EXE. :-)

The throw and catch should be in the same DLL or EXE and compiled with the
same C++ compiler and settings. The non-C++ code could be linked into the
same module or from a different DLL.

regards,
George

"Ben Voigt [C++ MVP]" wrote:

"George" <George@discussions.microsoft.com> wrote in message
news:E337350B-556B-47E8-86D5-46CF4A9C52F1@microsoft.com...

Sure, Ben!

When linking C and C++ code together, the C++ throw statement will
correctly
find the innermost matching enclosing C++ catch statement just fine,
ignoring any non-C++ code in the call stack. If that non-C++ code
expected
to continue running at some point, well too bad.

This is also what I expected but I have not found any formal documents
covering mixing C/C++ and exception handling. Do you have any formal
documents to support your points?

Only the fact that the C++ standard sections on exception handling don't
permit different behavior simply because there is a non-C++ function in
the
call stack. Also the C++ standard only requires destruction of C++ auto
variables during unwinding, there is no limitation on what is done with
non-C++ data in the stack.

As long as the throw and catch statements are in the same module, then a
C++
compiler has to make them work correctly or else it is not
standards-conforming.

If the throw and catch statements are in different modules, maybe using
different C++ compilers, then they need not be visible to each other.

regards,
George

"Ben Voigt [C++ MVP]" wrote:

"George" <George@discussions.microsoft.com> wrote in message
news:88C9FF33-9C55-491F-B7E2-B3B7FA0C8CC7@microsoft.com...

Thanks for correcting Ben!

The C++ exception logic provided by the compiler does adjust the
stack
pointer. This is done by a write to the EBP and ESP registers, not
a
jmp
instruction.

I have studied this issue for a couple of days. Now I think it
should
be
undefined behavior if exception thrown from C++ to C code. The
correct
solution should be,

1. Let C++ code catch exception and return error code to C code;
2. C code return error code to C++ caller;
3. C++ caller transform error code from C into exception.

Agree or any further comments?

This is a good method if the caller and callee are in different
modules
(and
may be in different programming languages or environments).

When linking C and C++ code together, the C++ throw statement will
correctly
find the innermost matching enclosing C++ catch statement just fine,
ignoring any non-C++ code in the call stack. If that non-C++ code
expected
to continue running at some point, well too bad.

regards,
George

"Ben Voigt [C++ MVP]" wrote:

"George" <George@discussions.microsoft.com> wrote in message
news:9A40A513-E943-40D9-81B7-99A2EE049DB1@microsoft.com...

Hi Tim,

No. jmp changes the flow of the code. It doesn't affect the
stack.
Exception unwinding is more complicated than this.

I understand unwinding is more complex. But we are talking about
exception
thrown from C++ to C. I think there is no exception registration
entry
in
C
qsort, and what I mean is the major work is jump to higher
address
space
to
look for exception handler. When you jump to higher address to
look
for
exception handler, current lower address stack will be
disgarded --
this
is
how stack object on C function qsort is freed automatically.

The C++ exception logic provided by the compiler does adjust the
stack
pointer. This is done by a write to the EBP and ESP registers, not
a
jmp
instruction.

If I missed anything important, please feel free to correct me.
:-)

regards,
George

"Tim Roberts" wrote:

George <George@discussions.microsoft.com> wrote:

memory on the stack. Local POD-style stack variables will be
freed
gracefully even if an exception happens.

I assume it is implemented by a simple jmp assembly command to
a
higher
memory address? Right?

No. jmp changes the flow of the code. It doesn't affect the
stack.
Exception unwinding is more complicated than this.

2.

Any comments about why modern C++ library implements qsort in
C,
why
not
in
C++?

Because it is ridiculous to rewrite something that doesn't need
rewriting.
The qsort routine in C run-time libraries is well-established,
well-tested,
and well-optimized. The C++ run-time library needs EXACTLY the
same
routine, with EXACTLY the same parameters and EXACTLY the same
semantics.
Why on earth wouldn't you use EXACTLY the same code?

(you see, almost all the libraries -- like STL algorithms --
are
C++,
why
leaving qsort as a legacy C function?)

It's just not true. STL is C++, because it needs templates, but
"almost
all the libraries" is just not true.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.