No subject

[Fred Tydeman]

Subject: How merge NCEG and/or LCAS into ANSI C.
 
The Numerical C Extensions Group NCEG (X3J11.1) has not had much
discussion on how its work is supposed to fit in with ANSI C (X3J11).  I
can think of four ways:
 
1) Have ANSI C adopt NCEG as a change to the standard.  That would mean
   that existing compilers, headers and libraries would need to be
   changed to support additional features as standard.  For example,
   that would mean that strtod("INFINITY",&ptr); would be part of the
   standard "C" locale.  This is probably too strong a change.
 
2) Have the NCEG extensions only be effective if certain predefined
   macro names are defined (say, via a compiler command line option).
   There may be different levels of support to different parts of the
   NCEG extensions, e.g., __NCEG__ for everything, __FPCE__ for floating
   point C extensions, __FPCE_IEEE__ for IEEE-754 implementations of
   floating point C extensions.  This implies that there be another set
   of libraries and headers.  So now there may be strict ANSI, POSIX,
   and X/OPEN, NCEG, and LCAS versions.  This would allow
   strtod("INFINITY",&ptr); to be part of the "C" locale to the
   NCEG_IEEE version of the libraries.  I assume that the compiler's
   behavior can be affected by "magic" macro names being defined.  Some
   things that may be changed are support for new syntax, semantics, and
   library functions.
 
3) Include a special header, say nceg.h, before all other headers, that
   would define "magic" macro names that would have the same effect as
   the previous option.  A problem with this is: "Headers may be
   included in any order;", line 29, page 97, 4.1.2 Standard Headers of
   ANSI X3.159-1989.
 
4) Change the locale to something other than the "C" locale, such as the
   "NCEG", "FPCE", "IEEE", or "LCAS" locale.  This would effect run time
   behavior of standard and extended functions, but would not affect
   compile time behavior.  Since some of the proposed NCEG changes are
   changes to syntax and semantics, there needs to be a compile time
   indication.  Hence this method is not general enough.
 
Aside:  The same kind of problem will exist for the Language Compatible
Arithmetic Standard (LCAS) of ANSI x3t2 if and when it is merged in with
ANSI C. My understanding of some of the effects LCAS would have on C
programs are:
 
   Require all integer overflows and divide-by-zeros be detected and
      acted upon.  This may mean that the compiler will have to
      generate additional code to detect integer overflow.
   Require all floating-point overflows, divide-by-zeros, and invalid
      operations be detected and acted upon.  An example of an invalid
      operation is 0.0 / 0.0.
 
Detected and acted upon means either:
1) Alteration of the control flow of the program such that execution can
   be continued only by explicit action as specified by the user within
   the program.  NOTE:  For example, notification might be accomplished
   by invoking a user-provided "error handler" routine.
 
   This means IEEE-754 math will conform to LCAS provided that trapping
   for "invalid", "overflow", and "zero-divide" exceptions are enabled.
   This conflicts with the NCEG IEEE proposal that all traps be disabled
   by default.
 
2) Output of a message indicating that a violation has occurred.  Such
   output should be to an external record or person, and should be done
   in a "hard to ignore" manner.  Post-notification behavior shall
   consist of either termination of execution of the program, or
   continuation of execution with some well-defined non-exceptional
   value of the appropriate type that replace the exceptional value.
 
   This to me means SQRT(-1.0); must print an error message and either
   terminate or return a numeric value, such as 0.0, and cannot return a
   NaN (which appears to violate what IEEE-754 wants).  Hence the LCAS
   version of the math library must be different than the NCEG IEEE
   version of the math library.
 
In summary, it looks like there are conflicting extensions to ANSI C and
the best way to allow those extensions is via option 2 to specify via
compile time command line options what version of "C" the user wants.
 
These are not IBM's views, these are the personal ones of:
Fred Tydeman, IBM, Palo Alto, Calif. (415) 855-4430
Internet: tydemanaibmpa.awdpa.ibm.com    uucp: uunet!ibmsupt!tydeman