EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Bill Tutt]

> David Starner wrote:
> Interesting. Wouldn't it be better just to add C++ exception handling,
though?
> It's substantially the same, but C++ EH is more general and has clear
effects
> with C++ EH over current implementations.

Um.. C++ exception handling semantics depend on classes/structs being
able to have destructors. Thus MS's creation of __finally.  The
difference between picking __catch vs. __except I would imagine was
done so it was visually different from the C++ spelling as to try and
reduce confusion as much as possible.

I think the only additional feature SEH has that C++ EH doesn't is the
ability to return to the code that through the exception. (returning
-1 from the __except filter expression)

The general keyword usage seems fairly sane to me, the extra features
that C++ doesn't require, and the exact MS specific behavior (aka
special return values from the __except() filter expression, and
resuming execution at the exception point) could certainly be tweaked
in some other way, but I'm sure the mingw32 folks would prefer the
semantics are as close as possible to the MS semantics so that they don't
have to alter their already existing code when they compile it with
mingw32.

So I guess I'm not sure why you think C++ EH is more general than SEH
since SEH is C++ EH without the language feature of destructors, and
SEH can restart execution at the point of failure.

> Less of a learning curve for most people, and if anyone 
> needs Microsoft EH, it shouldn't be that hard to port 
> over.

Bill

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX(gcc-2.95.1)

[llewelly]

On Mon, 31 Jan 2000, Bill Tutt wrote:

> > David Starner wrote:
> > Interesting. Wouldn't it be better just to add C++ exception handling,
> though?
> > It's substantially the same, but C++ EH is more general and has clear
> effects
> > with C++ EH over current implementations.
> 
> Um.. C++ exception handling semantics depend on classes/structs being
> able to have destructors. Thus MS's creation of __finally.  The
> difference between picking __catch vs. __except I would imagine was
> done so it was visually different from the C++ spelling as to try and
> reduce confusion as much as possible.

This is what catch(...) { throw;} is for. It works just like finally.

#include<stdio.h>
#include<stdexcept>
  using std::runtime_error;

void foo()
  {
    throw runtime_error("Barf!");
  }

void bar()
  {
    FILE* fp=fopen("foo","w");

    try
    {
      foo();
    }
    catch(...)
    {
      fclose(fp);
      printf("File closed.\n");
      throw;
    }
  }

int main()
  {
    try
    {
      bar();
    }
    catch(...)
    {
    }

    return(0);
  }


[snip]

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Richard Henderson]

On Tue, Feb 01, 2000 at 12:31:21AM -0700, llewelly@198.dsl.xmission.com wrote:
> This is what catch(...) { throw;} is for. It works just like finally.

No it doesn't -- __finally *always* runs, whether an
exception is thrown or not.


r~

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Zack Weinberg]

On Tue, Feb 01, 2000 at 12:19:42AM -0800, Richard Henderson wrote:
> On Tue, Feb 01, 2000 at 12:31:21AM -0700, llewelly@198.dsl.xmission.com wrote:
> > This is what catch(...) { throw;} is for. It works just like finally.
> 
> No it doesn't -- __finally *always* runs, whether an
> exception is thrown or not.

The other thing to consider here is we probably don't want to drag all
of RTTI into C.

zw

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX(gcc-2.95.1)

[llewelly]

On Tue, 1 Feb 2000, Richard Henderson wrote:

> On Tue, Feb 01, 2000 at 12:31:21AM -0700, llewelly@198.dsl.xmission.com wrote:
> > This is what catch(...) { throw;} is for. It works just like finally.
> 
> No it doesn't -- __finally *always* runs, whether an
> exception is thrown or not.

oops. Yes, I forgot about that. I guess my example needed another throw at
the end of its try{ } block.

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Richard Henderson]

On Tue, Feb 01, 2000 at 12:26:36AM -0800, Zack Weinberg wrote:
> The other thing to consider here is we probably don't want to drag all
> of RTTI into C.

I don't think that's really a problem.  Modulo the cancel-exception
thing, we could model MS EH like

	__try { foo(); }
	__except (some-test) { bar(); }
	__except (some-other-test) { baz(); }
to
	try { foo(); }
	catch (...) {
	  if (some-test) bar();
	  else if (some-other-test) baz();
	  else throw;
	}

Not quite as efficient as triggering off a type, but who ever
worried about run-time efficiency of exceptions, anyway.


r~

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Bill Tutt]

On Tue, 1 Feb 2000, Richard Henderson wrote:

> On Tue, Feb 01, 2000 at 12:26:36AM -0800, Zack Weinberg wrote:
> > The other thing to consider here is we probably don't want to drag all
> > of RTTI into C.
> 
> I don't think that's really a problem.  Modulo the cancel-exception
> thing, we could model MS EH like
> 
> 	__try { foo(); }
> 	__except (some-test) { bar(); }
> 	__except (some-other-test) { baz(); }
> to
> 	try { foo(); }
> 	catch (...) {
> 	  if (some-test) bar();
> 	  else if (some-other-test) baz();
> 	  else throw;
> 	}
> 
> Not quite as efficient as triggering off a type, but who ever
> worried about run-time efficiency of exceptions, anyway.
> 

MS EH doesn't support multiple __except blocks attached to one try block,
so this isn't a problem.
 
The annoying thing is that C based try/catch handlers need some kind of
information about the exception that occurred if they want to do any
useful processing. So if the C based try/catch handlers can't catch
asynchrnous exceptions (segv, divdie by zero, etc) and information about
C++ based exceptions is kind of useless is there any reason we need
try/catch for C at all? i.e. can we get away with just a try/finally pair?
This avoids the GetExceptionCode() problem altogether, but leaves
AbnormalTermination(), but that seems like a fairly simple gcc builtin to
code up.

Bill

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX(gcc-2.95.1)

[Oleg Krivosheev]

On Tue, 1 Feb 2000, Richard Henderson wrote:

> 
> On Tue, Feb 01, 2000 at 12:31:21AM -0700, llewelly@198.dsl.xmission.com wrote:
> > This is what catch(...) { throw;} is for. It works just like finally.
> 
> No it doesn't -- __finally *always* runs, whether an
> exception is thrown or not.
> 

well, i believe you could rethrow the exception and get the
catch(...) block always run. Just add throw; in appropriate place

OK

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Zack Weinberg]

On Tue, Feb 01, 2000 at 02:05:59AM -0800, Bill Tutt wrote:
> 
> The annoying thing is that C based try/catch handlers need some kind of
> information about the exception that occurred if they want to do any
> useful processing. So if the C based try/catch handlers can't catch
> asynchrnous exceptions (segv, divdie by zero, etc) and information about
> C++ based exceptions is kind of useless is there any reason we need
> try/catch for C at all? i.e. can we get away with just a try/finally pair?
> This avoids the GetExceptionCode() problem altogether, but leaves
> AbnormalTermination(), but that seems like a fairly simple gcc builtin to
> code up.

The usual reason people want exceptions in C is to make pthread
cancellation play nice with C++.  The pthread library has 'cleanups'
that happen when a thread is cancelled, that are basically
try/finally, but they don't interoperate with the C++ exception
mechanism.  What you'd like is for pthread_cleanup_push/pop to be
implemented in terms of try/catch, and pthread_cancel to throw an
exception in the cancelled thread.

That requires only try { } catch (...) { }, plus some way to throw
an object (not just rethrow), in C.

zw

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Bill Tutt]

On Tue, 1 Feb 2000, Zack Weinberg wrote:

> On Tue, Feb 01, 2000 at 02:05:59AM -0800, Bill Tutt wrote:
> > 
> > The annoying thing is that C based try/catch handlers need some kind of
> > information about the exception that occurred if they want to do any
> > useful processing. So if the C based try/catch handlers can't catch
> > asynchrnous exceptions (segv, divdie by zero, etc) and information about
> > C++ based exceptions is kind of useless is there any reason we need
> > try/catch for C at all? i.e. can we get away with just a try/finally pair?
> > This avoids the GetExceptionCode() problem altogether, but leaves
> > AbnormalTermination(), but that seems like a fairly simple gcc builtin to
> > code up.
> 
> The usual reason people want exceptions in C is to make pthread
> cancellation play nice with C++.  The pthread library has 'cleanups'
> that happen when a thread is cancelled, that are basically
> try/finally, but they don't interoperate with the C++ exception
> mechanism.  What you'd like is for pthread_cleanup_push/pop to be
> implemented in terms of try/catch, and pthread_cancel to throw an
> exception in the cancelled thread.
> 
> That requires only try { } catch (...) { }, plus some way to throw
> an object (not just rethrow), in C.
> 

I'm afraid I don't know anything about pthreads, although I do vaguely
recall people discussing the problem you mention. I'm just not sure I
follow why you think __try/__finally in C doesn't interoperate with the
C++ exception mechanism. Perhaps you could enlighten me more on the
details of the pthread problem?

A __finally block is simply the equivalent of a C++ destructor that needs
to get called when the exception handling mechanism is unwinding the stack
to the exception handler itself.

If you use try {} catch(...) {} you'll end up having code like this:
try
{
  ....
}
catch(...)
{
  cleanup();
}
cleanup();

Which looks frightfully silly to me. If you're only talking about
synchrnous exception handling, I still don't see why C would need a
try/catch syntax since it doesn't have any useful understanding of the
exception state at all. 

On the other hand, if you just want to avoid deviating from a subset of
the C++ syntax then you will end up having code like the above. Which I
suppose is fine, just make sure you make that design decision explicit in
the docs.

Bill

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Bill Tutt]

On Tue, 1 Feb 2000, Bill Tutt wrote:

> Which looks frightfully silly to me. If you're only talking about
> synchrnous exception handling, I still don't see why C would need a
> try/catch syntax since it doesn't have any useful understanding of the
> exception state at all. 
> 

Unless of course you do want to give C some understanding of the C++
exception state, which I haven't seen anyone even come close to
suggesting.

Bill

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Zack Weinberg]

On Tue, Feb 01, 2000 at 12:49:01PM -0800, Bill Tutt wrote:
> 
> 
> On Tue, 1 Feb 2000, Bill Tutt wrote:
> 
> > Which looks frightfully silly to me. If you're only talking about
> > synchrnous exception handling, I still don't see why C would need a
> > try/catch syntax since it doesn't have any useful understanding of the
> > exception state at all. 
> 
> Unless of course you do want to give C some understanding of the C++
> exception state, which I haven't seen anyone even come close to
> suggesting.

I believe that is exactly what people want.  To be more specific,
system libraries written in C need to be able to generate exceptions
in a C++ compatible fashion, and cope with exceptions thrown through
them from callbacks.  The pthreads library is the obvious example
since it has a pseudo- exception facility built in
(pthread_cleanup_push).

Given that, it makes most sense to make the C syntax and semantics be
as close to C++ as possible.  We can't import the C++ model wholesale
because it depends on RTTI and objects, but I think that

  __try {
     /* code */
  } __catch {
     /* clean up */
     __throw;
  }
  /* maybe clean up here too */

invents fewer new concepts than adding a __finally.  Also note that
pthread_cleanup_pop() does not always execute the cleanup function you
registered earlier.

Another thing to think about - it'd be Nice if setjmp/longjmp
interoperated with throw/catch, partially because that would make the
behavior politer to C++ code, partially because the compiler would
comprehend control flow better.  (On second thought, there may be code
out there that expects that longjmp() will go directly to its target,
not visiting catch handlers and not collecting $200.)

zw

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX(gcc-2.95.1)

[llewelly]

On Tue, 1 Feb 2000, Zack Weinberg wrote:

> On Tue, Feb 01, 2000 at 12:49:01PM -0800, Bill Tutt wrote:
> > 
> > 
> > On Tue, 1 Feb 2000, Bill Tutt wrote:
> > 
> > > Which looks frightfully silly to me. If you're only talking about
> > > synchrnous exception handling, I still don't see why C would need a
> > > try/catch syntax since it doesn't have any useful understanding of the
> > > exception state at all. 
> > 
> > Unless of course you do want to give C some understanding of the C++
> > exception state, which I haven't seen anyone even come close to
> > suggesting.
> 
> I believe that is exactly what people want.  To be more specific,
> system libraries written in C need to be able to generate exceptions
> in a C++ compatible fashion, and cope with exceptions thrown through
> them from callbacks.  The pthreads library is the obvious example
> since it has a pseudo- exception facility built in
> (pthread_cleanup_push).

Currently, you can compile C code with -fexceptions, and throw C++
  exceptions across the resulting functions. I have found this to very
  useful, even necessary at times. 

If system libraries (written in C) generate exceptions. I would like to be
  able catch them in C++ code, preferably with the standard C++ exception
  syntax and semantics. More importantly, I want C++ destructors to be
  called when the stack is unwound.

So yes, what you are talking about is what I want most.

> 
> Given that, it makes most sense to make the C syntax and semantics be
> as close to C++ as possible.  We can't import the C++ model wholesale
> because it depends on RTTI and objects, but I think that
> 
>   __try {
>      /* code */

Perhaps I shouldn't open my mouth and stick my foot in it again, but
  aren't you missing a '__throw;' here, so the cleanup code will get
  called even if an exception is thrown? That way you don't need two sets
  of cleanup code. (of course, there is the performance penaly of the
  __throw;)

>   } __catch {
>      /* clean up */
>      __throw;
>   }
>   /* maybe clean up here too */
> 
> invents fewer new concepts than adding a __finally.  Also note that
> pthread_cleanup_pop() does not always execute the cleanup function you
> registered earlier.
> 
> Another thing to think about - it'd be Nice if setjmp/longjmp
> interoperated with throw/catch, partially because that would make the
> behavior politer to C++ code, partially because the compiler would
> comprehend control flow better.  (On second thought, there may be code
> out there that expects that longjmp() will go directly to its target,
> not visiting catch handlers and not collecting $200.)
> 
> zw
> 

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Bill Tutt]

On Tue, 1 Feb 2000 llewelly@198.dsl.xmission.com wrote:

> 
> 
> On Tue, 1 Feb 2000, Zack Weinberg wrote:
> 
> > On Tue, Feb 01, 2000 at 12:49:01PM -0800, Bill Tutt wrote:
> > > 
> > > 
> > > On Tue, 1 Feb 2000, Bill Tutt wrote:
> > > 
> > > > Which looks frightfully silly to me. If you're only talking about
> > > > synchrnous exception handling, I still don't see why C would need a
> > > > try/catch syntax since it doesn't have any useful understanding of the
> > > > exception state at all. 
> > > 
> > > Unless of course you do want to give C some understanding of the C++
> > > exception state, which I haven't seen anyone even come close to
> > > suggesting.
> > 
> > I believe that is exactly what people want.  To be more specific,
> > system libraries written in C need to be able to generate exceptions
> > in a C++ compatible fashion, and cope with exceptions thrown through
> > them from callbacks.  The pthreads library is the obvious example
> > since it has a pseudo- exception facility built in
> > (pthread_cleanup_push).
> 

Well, that either means your system library isn't all C code (the
easiest thing to do) or just means you want some mechanism in C to throw
some kind of exception, that C++ can catch.

Three possible choices are:
1) __throw; All alone by itself, passing utterly no state along with the
exception, and only catchable by C++ with catch(...).
That doesn't seem to make much sense.
2) __throw(<int expression); This would allow C++ to catch it with
catch(int i) and then do additional filtering based on the value of i.
(assuming its legal C++, and implementable)
3) What MS does. For details on what MS does to accomplish translating the
SEH exception into a C++ typed exception see: 
http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_crt__set_se_translator.htm

There may be other possibilites, but those are the immediate ones that
come to mind.

Bill

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Zack Weinberg]

On Tue, Feb 01, 2000 at 02:32:52PM -0700, llewelly@198.dsl.xmission.com wrote:
> On Tue, 1 Feb 2000, Zack Weinberg wrote:
> > On Tue, Feb 01, 2000 at 12:49:01PM -0800, Bill Tutt wrote:
> > > Unless of course you do want to give C some understanding of the C++
> > > exception state, which I haven't seen anyone even come close to
> > > suggesting.
> > 
> > I believe that is exactly what people want.  To be more specific,
> > system libraries written in C need to be able to generate exceptions
> > in a C++ compatible fashion, and cope with exceptions thrown through
> > them from callbacks.  The pthreads library is the obvious example
> > since it has a pseudo- exception facility built in
> > (pthread_cleanup_push).
> 
> Currently, you can compile C code with -fexceptions, and throw C++
>   exceptions across the resulting functions. I have found this to very
>   useful, even necessary at times. 

Yes.  Of course, to extend C for exceptions, we'd have to turn on
-fexceptions for C, and the code size increase was judged to be
unacceptable.

It seems to me that the .eh_frame information could be shrunk down
substantially by not emitting unwind data for positions where we know
an exception can't be generated.  Example:

extern void f(int x) throw ();
extern void g(int x);

void h(void)
{
  f(1);
  g(2);
}

compiles as:

.globl h__Fv
        .type    h__Fv,@function
h__Fv:
.LFB1:
        subl    $24, %esp
        pushl   $1
.LCFI0:
.LCFI1:
        call    f__Fi
        subl    $12, %esp
        pushl   $2
.LCFI2:
.LCFI3:
        call    g__Fi
        addl    $44, %esp
        ret
.LCFI4:
.LFE1:

plus 60 bytes of frame info.  It is so large at least partially
because we have emitted instructions on how to unwind the stack from
any point in the function.  But the only place in this function that
can throw is the call to g__Fi, so most of it is unnecessary.  (Mind,
I have no idea how much smaller it'd get if we did that optimization.
Is there a disassembler for DWARF2 anywhere?)

...
> >   __try {
> >      /* code */
> 
> Perhaps I shouldn't open my mouth and stick my foot in it again, but
>   aren't you missing a '__throw;' here, so the cleanup code will get
>   called even if an exception is thrown? That way you don't need two sets
>   of cleanup code. (of course, there is the performance penaly of the
>   __throw;)

In this example, not if I want to return normally from the function.
The catch handler did a rethrow.

zw

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Bill Tutt]

On Tue, 1 Feb 2000, Zack Weinberg wrote:

[__try/__catch]
> invents fewer new concepts than adding a __finally.  Also note that
> pthread_cleanup_pop() does not always execute the cleanup function you
> registered earlier.
> 

While its true that it invents fewer concepts, I'm not exactly sure why
you think thats a useful metric to use when it causes the sideeffect of
having to write the cleanup code twice. 

> Another thing to think about - it'd be Nice if setjmp/longjmp
> interoperated with throw/catch, partially because that would make the
> behavior politer to C++ code, partially because the compiler would
> comprehend control flow better.  (On second thought, there may be code
> out there that expects that longjmp() will go directly to its target,
> not visiting catch handlers and not collecting $200.)
> 

Just as more of an FYI, MS stuck versions of setjmp/longjmp in setjmpex.h
or something similar that does use the stack unwinding information.

Bill

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Geoff Keating]

Zack Weinberg <zack@wolery.cumb.org> writes:

> On Tue, Feb 01, 2000 at 02:05:59AM -0800, Bill Tutt wrote:
> > 
> > The annoying thing is that C based try/catch handlers need some kind of
> > information about the exception that occurred if they want to do any
> > useful processing. So if the C based try/catch handlers can't catch
> > asynchrnous exceptions (segv, divdie by zero, etc) and information about
> > C++ based exceptions is kind of useless is there any reason we need
> > try/catch for C at all? i.e. can we get away with just a try/finally pair?
> > This avoids the GetExceptionCode() problem altogether, but leaves
> > AbnormalTermination(), but that seems like a fairly simple gcc builtin to
> > code up.
> 
> The usual reason people want exceptions in C is to make pthread
> cancellation play nice with C++.  The pthread library has 'cleanups'
> that happen when a thread is cancelled, that are basically
> try/finally, but they don't interoperate with the C++ exception
> mechanism.  What you'd like is for pthread_cleanup_push/pop to be
> implemented in terms of try/catch, and pthread_cancel to throw an
> exception in the cancelled thread.
> 
> That requires only try { } catch (...) { }, plus some way to throw
> an object (not just rethrow), in C.

Is there some reason why pthread_cleanup_push/pop can't be implemented
in C++ (with 'extern "C"', of course)?

It strikes me that there's no point modifying the C compiler until it
has most of the feature set of the C++ compiler, because we already
have such a thing called 'g++'.  And look, you get templates and
operator overloading for free! :-)

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Zack Weinberg]

On Tue, Feb 01, 2000 at 03:37:02PM -0800, Geoff Keating wrote:
> Zack Weinberg <zack@wolery.cumb.org> writes:
> 
> > The usual reason people want exceptions in C is to make pthread
> > cancellation play nice with C++.  The pthread library has 'cleanups'
> > that happen when a thread is cancelled, that are basically
> > try/finally, but they don't interoperate with the C++ exception
> > mechanism.  What you'd like is for pthread_cleanup_push/pop to be
> > implemented in terms of try/catch, and pthread_cancel to throw an
> > exception in the cancelled thread.
> > 
> > That requires only try { } catch (...) { }, plus some way to throw
> > an object (not just rethrow), in C.
> 
> Is there some reason why pthread_cleanup_push/pop can't be implemented
> in C++ (with 'extern "C"', of course)?

I don't think that would help any.  The effect of pthread_cleanup_push
is that if your thread is cancelled between it and the matching
pthread_cleanup_pop, the handler you specified gets called.  To make
that work with the exceptions mechanism, the code in between has to be
exception aware too.

zw

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Jamie Lokier]

Zack Weinberg wrote:
> Another thing to think about - it'd be Nice if setjmp/longjmp
> interoperated with throw/catch, partially because that would make the
> behavior politer to C++ code, partially because the compiler would
> comprehend control flow better.  (On second thought, there may be code
> out there that expects that longjmp() will go directly to its target,
> not visiting catch handlers and not collecting $200.)

I'm sure there's code out there that expects longjmp() to be reasonably
first, not arbitrarily slowly doing a data driven stack unwind.

longjmp() is also used from time to time to implement a dubious kind of
fake threads.

have a nice day,
-- Jamie

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Jamie Lokier]

Zack Weinberg wrote:
> The usual reason people want exceptions in C is to make pthread
> cancellation play nice with C++.  The pthread library has 'cleanups'
> that happen when a thread is cancelled, that are basically
> try/finally, but they don't interoperate with the C++ exception
> mechanism.  What you'd like is for pthread_cleanup_push/pop to be
> implemented in terms of try/catch, and pthread_cancel to throw an
> exception in the cancelled thread.
> 
> That requires only try { } catch (...) { }, plus some way to throw
> an object (not just rethrow), in C.

Actually all it requires is that the pthread_cleanup_push/pop functions
are compiled with the C++ compiler.  That would seem much easier than
extending the C language.  If the library is written to depend on some
GCC extension that was only written for that library anyway...  why not
bite the bullet and compile that one file with G++?

have a nice day,
-- Jamie

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Richard Henderson]

On Wed, Feb 02, 2000 at 01:24:48AM +0100, Jamie Lokier wrote:
> Actually all it requires is that the pthread_cleanup_push/pop functions
> are compiled with the C++ compiler.

They aren't functions.  They're macros, and they're used
all through libc to properly implement cancelation points.


r~

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Jamie Lokier]

Richard Henderson wrote:
> On Wed, Feb 02, 2000 at 01:24:48AM +0100, Jamie Lokier wrote:
> > Actually all it requires is that the pthread_cleanup_push/pop functions
> > are compiled with the C++ compiler.
> 
> They aren't functions.  They're macros, and they're used
> all through libc to properly implement cancelation points.

Ok ok, _pthread_cleanup_push/pop are the libc functions.
       ^

I gather they are not the functions that need this explicit unwinding
support though.  Something to do with thread creation needs it instead.

have a nice day,
-- Jamie

Re: EH in C (was: Re: (lack of) Thread-safe exceptions on AIX(gcc-2.95.1)

[Bill Tutt]

> llewley wrote:
> This is what catch(...) { throw;} is for. It works just like finally.

No it doesn't.
__finally() always gets executed. The catch(...) block is only executed 
when an exception is thrown.

In this example, the fprintf() always occurs. In your example if foo()
hadn't thrown the exception, the fclose() would never have gotten called.

__try
{
  .....
}
__finally
{
  fprintf("I'm inside of __finally.\n");
}

__finally's sole purpose in life is to give C code (not C++, C) the chance
to perform cleanup actions in the face of asynchrnous exceptions (divide
by zero, AV, etc), SEH generated synchronous exceptions, and C++ generated
synchrnous exceptions. SEH wouldn't need __finally if C supported
destructors, but C doesn't, and I don't think it should. 

Bill