From: Nicola Pero <nicola@brainstorm.co.uk>
To: Mark Mitchell <mark@codesourcery.com>
Cc: Zack Weinberg <zack@codesourcery.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests
Date: Fri, 08 Nov 2002 04:48:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.21.0211081158290.17515-100000@nicola.brainstorm.co.uk> (raw)
In-Reply-To: <147270000.1036722436@warlock.codesourcery.com>
> > 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.
next prev parent reply other threads:[~2002-11-08 12:48 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-05 15:16 [basic-improvements] try/finally support for c/c++ Aldy Hernandez
2002-11-05 15:57 ` Richard Henderson
2002-11-05 23:03 ` Aldy Hernandez
2002-11-06 0:44 ` Joseph S. Myers
2002-11-06 0:52 ` Jakub Jelinek
2002-11-06 3:02 ` Michael Matz
2002-11-06 3:11 ` Jakub Jelinek
2002-11-06 4:16 ` Michael Matz
2002-11-06 10:29 ` Aldy Hernandez
2002-11-06 10:53 ` Richard Henderson
2002-11-06 10:56 ` Aldy Hernandez
2002-11-06 11:24 ` Joseph S. Myers
2002-11-06 13:49 ` Richard Henderson
2002-11-06 17:45 ` Fergus Henderson
2002-11-07 9:54 ` Richard Henderson
2002-11-06 17:48 ` Fergus Henderson
2002-11-07 9:58 ` Richard Henderson
2002-11-06 11:22 ` Joseph S. Myers
2002-11-06 14:00 ` Richard Henderson
2002-11-06 17:21 ` Fergus Henderson
2002-11-06 4:20 ` Gabriel Dos Reis
2002-11-06 9:05 ` Aldy Hernandez
2002-11-06 9:11 ` Matt Austern
2002-11-06 9:25 ` Gabriel Dos Reis
2002-11-06 11:15 ` Richard Henderson
2002-11-07 0:09 ` Kai Henningsen
2002-11-07 12:56 ` Richard Henderson
2002-11-06 6:05 ` Jason Merrill
2002-11-06 10:56 ` Richard Henderson
2002-11-06 12:14 ` Jason Merrill
2002-11-05 16:40 ` Stan Shebs
2002-11-05 16:48 ` Matt Austern
2002-11-05 17:21 ` Jason Merrill
2002-11-05 19:25 ` Matt Austern
2002-11-06 10:25 ` Richard Henderson
2002-11-06 11:05 ` Mike Stump
2002-11-05 21:20 ` Aldy Hernandez
2002-11-06 9:43 ` [basic-improvements] try/finally support for c/c++ - more tests Jakub Jelinek
2002-11-06 11:04 ` Joseph S. Myers
2002-11-06 15:34 ` Mark Mitchell
2002-11-06 16:03 ` Richard Henderson
2002-11-06 16:10 ` Gabriel Dos Reis
2002-11-06 16:12 ` Richard Henderson
2002-11-06 16:20 ` Gabriel Dos Reis
2002-11-06 17:02 ` Per Bothner
2002-11-06 17:14 ` Gabriel Dos Reis
2002-11-06 16:47 ` Mark Mitchell
2002-11-06 16:54 ` Matt Austern
2002-11-06 18:00 ` Zack Weinberg
2002-11-06 18:14 ` Gabriel Dos Reis
2002-11-06 18:58 ` Zack Weinberg
2002-11-06 19:33 ` Gabriel Dos Reis
2002-11-06 22:15 ` Zack Weinberg
2002-11-06 22:37 ` Mark Mitchell
2002-11-06 23:30 ` Aldy Hernandez
2002-11-07 1:03 ` Gabriel Dos Reis
2002-11-07 5:34 ` Michael Matz
2002-11-07 8:14 ` Mark Mitchell
2002-11-07 8:37 ` Daniel Jacobowitz
2002-11-07 9:09 ` Mark Mitchell
2002-11-07 9:19 ` Daniel Jacobowitz
2002-11-07 9:53 ` Mark Mitchell
2002-11-07 9:57 ` Matt Austern
2002-11-07 10:43 ` Jason Merrill
2002-11-07 8:44 ` Jakub Jelinek
2002-11-07 12:18 ` Geoff Keating
2002-11-07 12:24 ` Daniel Jacobowitz
2002-11-07 12:32 ` Mark Mitchell
2002-11-07 13:41 ` Geoff Keating
2002-11-07 14:06 ` Mark Mitchell
2002-11-07 14:39 ` Richard Henderson
2002-11-07 14:53 ` Mark Mitchell
2002-11-07 15:14 ` Geoff Keating
2002-11-07 15:37 ` Mark Mitchell
2002-11-08 11:30 ` Geoff Keating
2002-11-07 15:45 ` Richard Henderson
2002-11-07 16:21 ` Mark Mitchell
2002-11-07 16:44 ` aldyh
2002-11-07 17:06 ` Richard Henderson
2002-11-07 17:10 ` Jakub Jelinek
2002-11-07 17:29 ` Mark Mitchell
2002-11-07 17:43 ` Richard Henderson
2002-11-07 17:55 ` Mark Mitchell
2002-11-07 17:52 ` Jason Merrill
2002-11-07 17:57 ` Mark Mitchell
2002-11-07 18:17 ` Zack Weinberg
2002-11-07 18:29 ` Mark Mitchell
2002-11-07 21:23 ` Robert Lipe
2002-11-07 21:32 ` Jason Merrill
2002-11-08 4:48 ` Nicola Pero [this message]
2002-11-08 5:47 ` Jakub Jelinek
2002-11-08 10:02 ` Fergus Henderson
2002-11-08 11:24 ` Kai Henningsen
2002-11-08 11:44 ` Jakub Jelinek
2002-11-09 0:11 ` Fergus Henderson
2002-11-08 11:46 ` Mike Stump
2002-11-08 10:02 ` Matt Austern
2002-11-11 5:38 ` Michael Matz
2002-11-11 12:59 ` Matt Austern
2002-11-12 1:01 ` Michael Matz
2002-11-12 8:20 ` Mark Mitchell
2002-11-12 8:58 ` Michael Matz
2002-11-07 19:28 ` Daniel Jacobowitz
2002-11-07 22:07 ` Alexandre Oliva
2002-11-08 4:27 ` Richard Henderson
2002-11-08 4:54 ` Jakub Jelinek
2002-11-08 6:01 ` Jakub Jelinek
2002-11-08 11:38 ` Mike Stump
2002-11-08 11:25 ` Mike Stump
2002-11-08 9:31 ` Michael Matz
2002-11-08 11:26 ` Hans-Peter Nilsson
2002-11-08 11:48 ` Mike Stump
2002-11-07 11:38 ` Zack Weinberg
2002-11-07 9:38 ` Mike Stump
2002-11-07 10:06 ` Richard Henderson
2002-11-07 12:57 ` Hans-Peter Nilsson
2002-11-06 17:58 ` Fergus Henderson
2002-11-06 18:09 ` Fergus Henderson
2002-11-07 0:30 ` Jakub Jelinek
2002-11-06 18:34 ` Geoff Keating
2002-11-07 3:29 ` Fergus Henderson
2002-11-07 4:22 ` Jakub Jelinek
2002-11-07 5:13 ` Fergus Henderson
2002-11-07 5:47 ` Michael Matz
2002-11-07 8:52 ` Aldy Hernandez
2002-11-07 10:00 ` Mike Stump
2002-11-07 12:36 ` Alexandre Oliva
2002-11-07 13:06 ` Aldy Hernandez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.21.0211081158290.17515-100000@nicola.brainstorm.co.uk \
--to=nicola@brainstorm.co.uk \
--cc=gcc-patches@gcc.gnu.org \
--cc=mark@codesourcery.com \
--cc=zack@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).