[Cfp-interest] draft of syntax discussion for C committee

[David Hough CFP]

Here are some revisions based on Jim's comments, along with responses
on some of the comments:

=========================================

DIFF: 36,37c36,44

< traps, but with significant performance penalties for either the normal case 
< or exceptional case.
---
> traps, but that might entail significant performance penalties for either 
> the normal case or exceptional case.     Exceptions can be detected
> inline for each operation with tests on operands and results and flags -
> slowing down the normal case - or at the end of the try clause with flags -
> slowing the detection of the exceptional case (but testing flags alone does
> not detect exact underflow exceptions).    Instead of traps,
> some existing hardware such as
> PowerPC can exploit its unconventional conditional branch instructions 
> to detect exceptions.

COMMENT:

[
> Is how to implement alternate exception handling without traps 
> (including for underflow) documented somewhere?

Not that I know of - the general idea is mentioned here; how that works out
in detailed code generation depends on the hardware architecture, but we
could write up some hints that look like C code - 
but I don't think this document is the place for it.
]

=========================================

DIFF: 150,151c157,160

< But having to specify the same exception-list in two different places
< seems error-prone.
---
> Compilers that would process the catch_fe clauses before generating the
> try clause code could ignore that pragma.
> One-pass compilers that encountered discrepancies in catch_fe clauses 
> from the exceptions flagged in advance should probably generate errors.

COMMENT:

[
> It doesn't need to be error prone. The CATCH_AHEAD exception list could be required to be a super set of all the catch_fe exception lists, which the compiler could check. The advantages would be a concise statement of exceptions that might get alternate exception handling and not having to see all the exception code before getting to the main code - which I believe would make the code more readable.

Actually the simplest method for doing what Jim proposes without duplicating
effort might be like this:

 {
 #pragma STDC catch_fe fe_exception1 label1
 #pragma STDC catch_fe fe_exception2 label2
  ... normal case code
 }
  ... normal case continues here
 label1:
  ... exception case 1 code
 label2:
  ... exception case 2 code
 
You don't need exception lists any more - list one exception at a time
even if they both go to the same place.
The above is entirely freed from block structure... or not:

 {
 #pragma STDC catch_fe fe_exception1 label1
 #pragma STDC catch_fe fe_exception2 label2
  ... normal case code
  break;
 label1:
  ... exception case 1 code
 label2:
  ... exception case 2 code
 }
 ... normal case continues here

Putting it into C++ try/catch form requires a way of creating a type
from an exception name:

 try {
 #pragma STDC catch_fe fe_exception1
 #pragma STDC catch_fe fe_exception2
  ... normal case code
 }
 catch (FE_EXCEPTION_TYPE(fp_exception1) e1) {
  ... exception case 1 code
 }
 catch (FE_EXCEPTION_TYPE(fp_exception2) e2) {
  ... exception case 2 code
 }
 ... normal case continues here

FE_EXCEPTION_TYPE is a standard macro that converts an <fenv.h> exception
like FE_INVALID (which is just an implementation-defined integer 
representing a bit in a field) into a type FE_INVALID_TYPE,
since C++ style catch works on the type of its argument.
Whatever is actually in the variable e1 or e2 doesn't matter because it's
not likely to be in a form useful in a portable program.

I don't regard defining FE_EXCEPTION_TYPE 
as doing the application programmer any favor.
I'd much rather write
 catch_fe(fp_exception1)
than 
 catch (FE_EXCEPTION_TYPE(fp_exception1) e1)

The point is that it could be made to look more or less like C++
if that were deemed important enough.
]

=========================================

DIFF: 156,160c164,168

< exception handling could be added to C++ with minimal syntactic 
< effort, and most of
< C++ exception handling could be added to C with minimal syntactic 
< effort.
< If that compatibility is deemed to be of low value, 
---
> exception handling could be added to C++ with less syntactic 
> effort than other possible approaches, and most of
> C++ exception handling could be added to C with less syntactic 
> effort than other possible approaches.
> If that compatibility were deemed to cost more than its benefit,

COMMENT:

[
>> One result of preserving some form of try/catch syntax is that 
>> floating-point
>> exception handling could be added to C++ with minimal syntactic effort, 

>Is this true? Has it been done?

>> and most of
>> C++ exception handling could be added to C with minimal syntactic effort.

>Really? We don't have a specification of the changes to C required to add such syntax.

Neither of these has been done.
But they would require minimal syntactic effort 
compared to a completely different syntax.     
That doesn't address the effort to implement the semantics.
]

[
>> If that compatibility is deemed to be of low value

> Not a fair statement. C and C++ compatibility is certainly of value, and it might be regarded as a reasons for not adding a different specialized try-catch.

I should have used the subjunctive here - I really don't know if there is
consensus one way or another on the C committee on this point.
]