From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23560 invoked by alias); 8 Nov 2002 12:48:55 -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 23548 invoked from network); 8 Nov 2002 12:48:54 -0000 Received: from unknown (HELO mail.brainstorm.co.uk) (217.169.5.196) by sources.redhat.com with SMTP; 8 Nov 2002 12:48:54 -0000 Received: from nicola.brainstorm.co.uk (nicola.brainstorm.co.uk [192.168.4.138]) by mail.brainstorm.co.uk (8.11.4/8.11.4) with ESMTP id gA8Cmn218502; Fri, 8 Nov 2002 12:48:49 GMT Date: Fri, 08 Nov 2002 04:48:00 -0000 From: Nicola Pero To: Mark Mitchell cc: Zack Weinberg , "gcc-patches@gcc.gnu.org" Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests In-Reply-To: <147270000.1036722436@warlock.codesourcery.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-11/txt/msg00562.txt.bz2 > > Y'know, I don't see why people would think that. It doesn't have > > __except or __catch or whatever Microsoft calls it, and we say > > explicitly that this is only for pthread_cancel() and for exceptions > > thrown by other language runtimes... > > Maybe I have been so often burned by these language extensions that I > am overly paranoid. It's certainly possible, and Matt Austern has > stopped commenting, so he is perhaps convinced, leaving me as a lone > voice of insane conservatism. 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++. Shall we "finally try" to talk a bit about this C language extension from a C user perspective, without jumping into C++ every sentence ? I've got a lot of doubts that this extension is good for C, at least as it is. In C there is no exception handling, so it's common for C libraries to implement some sort of exception handling using setjmp/longjmp. As far as I understand, the proposed feature wouldn't be enough powerful to replace the existing setjmp/longjmp based exception handling. Actually, the proposed feature would actually not work with the existing setjmp/longjmp based exception handling ... either you use the new feature (which is not enough powerful to provide exception handling), or you use setjmp/longjmp. As a C/ObjC user, I don't find this solution very satisfactorily. We've been long waiting for "real" exception handling in C/ObjC ... and this is *not* it. I'd like to see the thing discussed more in details from a pure C point of view, ignoring C++. It's an extension to C, not to C++. This thread was full of explanations such as "the real purpose of try/finally is that if an exception is thrown in try, the code in finally is executed", which is not particularly convincing for C/ObjC users, since we can't throw any exceptions in C/ObjC! :-) (the patch does not provide support for it), except possibly some custom/hackish setjmp based exceptions, which finally can't catch. As far as I understand from the explanations on this thread, try/finally in C would only be used to cleanup before returning from a function, such as try { char *stringA = NULL; char *stringB = NULL; char *stringC = NULL; stringA = malloc (sizeof (char) * 20); if (stringA == NULL) return; ... stringB = malloc (sizeof (char) * 20); if (stringB == NULL) return; ... stringC = malloc (sizeof (char) * 20); if (stringC == NULL) return; ... return; } finally { if (stringA != NULL) free (stringA); if (stringB != NULL) free (stringB); if (stringC != NULL) free (stringC); } It's nice as an example, except I can trivially do it already without any need for a C extension: char *stringA = NULL; char *stringB = NULL; char *stringC = NULL; stringA = malloc (sizeof (char) * 20); if (stringA == NULL) goto finally; ... stringB = malloc (sizeof (char) * 20); goto finally; ... stringC = malloc (sizeof (char) * 20); if (stringC == NULL) goto finally; ... finally: { if (stringA != NULL) free (stringA); if (stringB != NULL) free (stringB); if (stringC != NULL) free (stringC); return; } (please pardon me for any syntax error, it's just a rough example, you get the idea). So I'm unconvinced by this C extension, which provides nothing new to the language - at least in this thread I've not been given any example of things you can do with it in C/ObjC which you couldn't already do by using a trivial label/goto construct (and please note that, in the example, the code without try/finally is portable, and only uses basic C constructs, while the example with try/finally is non portable, and requires you to know the semantics and syntax of GNU C extensions, so it's harder to read for non-GNU C programmers). Adding extensions with no use (except "making C more similar to C++") is quite like taking up lot more work without any actual compensation for it. I personally don't think that pthread_cleanup_* in C++ has much relevance to this discussion - it's a C/C++ interaction problem and we should not be changing the C language so deeply just to work around a C/C++ interaction problem. There must be other ways. Maybe changing C++. ;-) Having said all this, I'd really love to see real exception handling in C, so please pursue /real/ exception handling further! :-) But the whole point is that language extensions should be designed for the language users - to provide carefully designed useful facilities for the users of that language, not for the benefit of the users of another language. Else, try/finally should be renamed to something obscure such as __builtin_cplusplus_try and __builtin_cplusplus_finally (since it's only useful when C++ exceptions come into play), and deprecated in the doc for use from user code, and pthread_cleanup_* would be the only user of this extension - so that it's not really a generally available extension, but just for pthread_cleanup_* (and other C/C++ interaction stuff), and it's easy to drop the extension in the future whenever a better solution is there ... this might be ok, unless, well of course unless adding this thing would bloat all C files compiled with -lpthread with exception handling information tables [so that in C we get the bloating overhead in the object file, but not the actual exception handling features - very kind of you :-)] as someone seems to suggest - because if that's the case, no matter how you rename it, it's obviously not going to make C/ObjC users very happy. Sorry for providing criticism to the patch - I hope I've been able to concentrate on actual practical 'end-user' issues and problems which might lead to more explanations and useful discussions.