[basic-improvements] try/finally support for c/c++ - more tests

[Nicola Pero]

> > 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.