<font size=2 face="sans-serif">Not to derail the discussion, but Fred's
point about interaction with the existing C support for signal handlers
leads to the thoughts of the existing C support for (floating point) exceptions
in 7.6.2.</font>
<br>
<br><font size=2 face="sans-serif">I can't recall (nor can I find in my
notes) any discussion about extending what is already in the C standard
for floating point exceptions.</font>
<br>
<br><font size=2 face="sans-serif">Although arguably not as convenient
as what we are discussing right now, can we not add in new macros as we
are already discussing for the floating point exceptions, and use the existing
feclearexcept, fegetexceptflag, feraiseexcept, fesetexceptflag, and fetestexcept
functions? </font>
<br>
<br><font size=2 face="sans-serif">The example code given in the standard
shows how to do pretty much everything we are discussing, though more verbosely.</font>
<br>
<br><font size=2 face="sans-serif">The advantages are that it is building
on something that is already in the C standard and hence more easily accepted
by both the C committee, implementers and users due to its familiarity,
and avoids "ugly" pragmas. Also, the signal handling issue falls
under the current C standard model so we do not need to specify anything
extra here (whereas we would for the try-catch/pragma style model).</font>
<br>
<br><font size=2 face="sans-serif">The disadvantages are that it is not
as "clean" as the C++ style exception handling, it may make it
harder for optimizing compilers to recognize the exception pattern (though
I would argue it is actually easier on the compiler and hardware with the
current C standard way), and in a non-optimizing case, may be much slower
on some hardware.</font>
<br>
<br><font size=2 face="sans-serif">Now there may be the issue of lack of
bits (given exceptions are stored in int's from the interface) on some
implementations, but that can be worked around (ex. version check, or even
a new set of functions created for these new sub-exceptions).</font>
<br>
<br><font size=2 face="sans-serif">Regards,<br>
<br>
Rajan Bhakta<br>
z/OS XL C/C++ Compiler Technical Architect<br>
ISO C Standards Representative for Canada<br>
C Compiler Development<br>
Contact: rbhakta@us.ibm.com, Rajan Bhakta/Houston/IBM</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Fred J. Tydeman"
<tydeman@tybor.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"cfp-interest@ucbtest.org"
<cfp-interest@ucbtest.org>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/06/2014 10:37 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [Cfp-interest]
draft of syntax discussion for C committee</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cfp-interest-bounces@oakapple.net</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On Fri, 6 Jun 2014 16:25:15 -0700 (PDT) David Hough
CFP wrote:<br>
><br>
> #pragma STDC catch_fe fe_exception1 label1<br>
> #pragma STDC catch_fe fe_exception2 label2<br>
<br>
What is the interaction between this idea and<br>
a signal handler for SIGFPE?<br>
<br>
<br>
---<br>
Fred J. Tydeman Tydeman Consulting<br>
tydeman@tybor.com Testing, numerics, programming<br>
+1 (775) 287-5904 Vice-chair of PL22.11 (ANSI "C")<br>
Sample C99+FPCE tests: </font></tt><a href=http://www.tybor.com/><tt><font size=2>http://www.tybor.com</font></tt></a><tt><font size=2><br>
Savers sleep well, investors eat well, spenders work forever.<br>
<br>
_______________________________________________<br>
Cfp-interest mailing list<br>
Cfp-interest@oakapple.net<br>
</font></tt><a href="http://mailman.oakapple.net/mailman/listinfo/cfp-interest"><tt><font size=2>http://mailman.oakapple.net/mailman/listinfo/cfp-interest</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>