From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31895 invoked by alias); 7 May 2003 10:18:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31590 invoked from network); 7 May 2003 10:18:37 -0000 Received: from unknown (HELO inet-mail4.oracle.com) (148.87.2.204) by sources.redhat.com with SMTP; 7 May 2003 10:18:37 -0000 Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h47AIaZ01790 for ; Wed, 7 May 2003 03:18:36 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h47AIZZ01727 for ; Wed, 7 May 2003 03:18:35 -0700 (PDT) Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h47AIYw29908 for ; Wed, 7 May 2003 04:18:34 -0600 (MDT) Received: from hotmail.com (incq135bc.idc.oracle.com [152.69.214.135]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id h47AIQg29760; Wed, 7 May 2003 04:18:27 -0600 (MDT) Message-ID: <3EB8DD9A.2050100@hotmail.com> Date: Wed, 07 May 2003 10:18:00 -0000 From: Ranjit Mathew User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jason@redhat.com CC: gcc@gcc.gnu.org Subject: Re: __attribute__((cleanup(function)) versus try/finally Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00608.txt.bz2 > 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/