Re: __attribute__((cleanup(function)) versus try/finally

[Ranjit Mathew <rmathew at hotmail dot com>]

> 2) implementing something before standardization
>
>   That's why the patch doesn't create "try" and "finally" keywords, but
>   rather "__try" and "__finally".  Though I can't imagine any similar
>   construct having different semantics.

Sorry to butt in into this discussion, but I would
like to point out that it would be a BAD idea to name
these "__try/__finally" simply because these are used
in the Windows world to deal with Windows Structured
Exception Handling (SEH) and are a language extension
introduced by MS Visual C/C++ (and adopted by other
commercial compilers for Windows):

http://msdn.microsoft.com/library/en-us/vccelng/htm/statem_31.asp

There are quite a few commercial and non-commercial
programs out there that use these keywords.

However unfortunate you consider this situation to be,
if GCC introduces these keywords, it is going to create
a lot of confusion.

The same issue was pointed out (albeit in passing)
when Aldy Hernandez had submitted his __try/__finally
patch to GCC for C.

Now I have an issue somewhat related to this
discussion that I hope someone would be able to
shed some light on: on Windows, the Cygwin/MinGW
targets have had to give up on DW2 EH in favour of
SJLJ purely because exceptions could not be
thrown from a callback function, across the
Windows Event Dispatcher stack to the handler
of the exception.

Such code is common in Windows GUI applications
created with GCC (MinGW).

The "core" message loop of such Windows GUI programs
is roughly like the following:

  while( GetMessage( &msg, NULL, 0, 0)) {
    try {
      TranslateMessage( &msg);
      DispatchMessage( &msg);
    } catch (...) {
      /* Whatever */
    }
  }

DispatchMessage( ) is a Win32 API that ultimately
delivers the message to a registered "window procedure"
callback function within the application that
handles this message and might possibly throw an
exception.

Since the Win32 API stack does not have DW2 EH
unwind information, the program just terminates
when an exception is thrown (if using DW2 EH).

SJLJ does not have any such problems.

In fact, this seems to be a fundamental limitation
of the DW2 EH mechanism and not just on Windows.

So is there a way out of this?

MD_FALLBACK_FRAME_STATE_FOR looks a bit promising
but how do we generalise it to any "foreign"
caller?

Many thanks in advance for answering these.

Ranjit.

--
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/