From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1954 invoked by alias); 8 Nov 2002 19:24:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 1886 invoked from network); 8 Nov 2002 19:24:08 -0000 Received: from unknown (HELO khms.westfalen.de) (62.153.201.243) by sources.redhat.com with SMTP; 8 Nov 2002 19:24:08 -0000 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.35 #1) id 18AEje-0005dI-00 (Debian); Fri, 08 Nov 2002 20:24:06 +0100 Received: by khms.westfalen.de (CrossPoint v3.12d.kh10 R/C435); 08 Nov 2002 20:23:13 +0200 Date: Fri, 08 Nov 2002 11:24:00 -0000 From: kaih@khms.westfalen.de (Kai Henningsen) To: gcc-patches@gcc.gnu.org Message-ID: <8$UZOT7Xw-B@khms.westfalen.de> In-Reply-To: <20021108084659.A10988@devserv.devel.redhat.com> Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <147270000.1036722436@warlock.codesourcery.com> <20021108084659.A10988@devserv.d X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-SW-Source: 2002-11/txt/msg00577.txt.bz2 jakub@redhat.com (Jakub Jelinek) wrote on 08.11.02 in <20021108084659.A10988@devserv.devel.redhat.com>: > On Fri, Nov 08, 2002 at 12:48:49PM +0000, Nicola Pero wrote: > > Well you're not a lone voice of insance conservatism, I actually think you > > are quite well giving voices to the puzzled C users, like me. :-) > > > > In all this discussion, I didn't quite find discussed how it would work in > > C/ObjC, from a pure C/ObjC perspective. Which IMO is essential to have > > the C extension approved. > > > > The suggestion that this change is good because "it makes C look more like > > C++ so that it's easier to integrate C and C++" might be good for C++ > > hackers and lovers, but it's definitely unconvincing for C/ObjC users with > > no interest in C++. > > If you look at a typical system nowadays, C and C++ has to easily integrate > together, as C++ code often calls C routines (starting from libstdc++ using > C library functions where C library is most often written in C) and a lot of > C programs/libraries are using C++ libraries too. But, just like Nicola, I don't care about that part because I don't use C++ myself. Let this be solved by C++, not by C! I *really* want *real* exception handling for C - doing this with setjmp/ longjmp (a.k.a. NS_DURING and friends) is just too ugly for words. Besides, it is dog slow - but this isn't it. > then you IMHO have all you need for satisfactory pure C exception handling > with minimal overhead. Minimal overhead? Your definition of minimal is certainly not mine. Setjmp/ longjmp based exceptions in C are *SLOW* even for code which doesn't raise exceptions. Besides, I'm sick and tired of "... may be clobbered by longjmp" because gcc cannot know how those jmp_buf's will be used. > a) typically in such functions they are not returning void, but some value, > with __try/__finally you can leave the code as above, just add the > return value to each return statement. With goto gem you need some > function scope variable and set it first, then return, > so if (stringC == NULL) return 134; becomes > if (stringC == NULL) { ret = 134; goto finally; } > which is less readable Look up NS_DURING and friends. It's not that it can't be hidden away in macrosm, because it can. It's that macros which expand with unbalanced braces are *extremely* easy to get wrong. And, of course, setjmp is no speed demon, and putting chaining on top of that doesn't help. MfG Kai