From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7744 invoked by alias); 9 May 2003 09:23:47 -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 7644 invoked from network); 9 May 2003 09:23:43 -0000 Received: from unknown (HELO hotmail.com) (65.54.245.114) by sources.redhat.com with SMTP; 9 May 2003 09:23:43 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 9 May 2003 02:23:44 -0700 Received: from 148.87.1.170 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 09 May 2003 09:23:43 GMT X-Originating-IP: [148.87.1.170] X-Originating-Email: [rmathew@hotmail.com] From: "Ranjit Mathew" To: rth@redhat.com Cc: gcc@gcc.gnu.org Bcc: Subject: Re: __attribute__((cleanup(function)) versus try/finally Date: Fri, 09 May 2003 09:23:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 09 May 2003 09:23:44.0051 (UTC) FILETIME=[AFBFD830:01C3160C] X-SW-Source: 2003-05/txt/msg00873.txt.bz2 > > The __finally block is executed in case of both "normal" C++ exceptions > > as well as "faults" such as accessing a NULL pointer, dividing by zero, > > etc. > >And your point is... ? Libjava does this for dwarf2 EH on Linux. Yes, I know (http://gcc.gnu.org/java/port-signals.html). The Windows port of GCJ also has a similar hack using SEH Win32 APIs. However, unlike signal handlers on Linux, Windows actually expects the "UnexpectedExceptionHandler" routine to *return* with a value to it - since the current implementation doesn't, a simple thing like two Java NullPointerExceptions results in a hung process on Win2K! So if we manage to make it work reliably, we can then claim identical semantics indeed. Touche. >Incidentally, I would be willing to review and incorporate pieces >of this into gcc. > >I can't promise anything about "__except" or "__leave" (indeed, I >suspect that they _won't_ be incorporated), but we can at least talk >about including SEH for general exception handling. At minimum you'd >be able to use catch(...) instead of "__except" in C++. This is good news for all MinGW users, thank you! Casper Hornstrup (chorns at users dot sourceforge dot net) of the ReactOS team, who has created the SEH enabled GCC mentioned earlier, would be delighted to hear this I think. Ranjit. _________________________________________________________________ Dreaming of a holiday? Make it happen. http://server1.msn.co.in/sp03/switzerlandtourism/index.asp In Switzerland!