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

[Jim Thomas]

On Jun 6, 2014, at 4:25 PM, David Hough CFP <pcfp at oakapple.net> wrote:

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

Consider omitting “unconventional”.

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

Right, this isn’t the place for such details. (I’m still wondering if some HW might not provide any way for a program to detect underflow exceptions.)

> ]
> 
> =========================================
> 
> 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,

The pragma approach adds nothing to the syntax of the language.

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

See previous comment.

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