* Document Number: WG14 N792/J11 97-156 C9X Revision Proposal ===================== * Title: C9X and LIA-1 informative annex. Author: Fred J. Tydeman Author Affiliation: Tydeman Consulting Postal Address: 3711 Del Robles Dr., Austin, Texas, 78727, USA E-mail Address: tydeman@tybor.com Telephone Number: +1 (512) 255-8696 Fax Number: +1 (512) 255-8696 Sponsor: WG14 Date: 1997-10-23 Document History: WG14 N758/J11 97-121. Proposal Category: Y_ Editorial change/non-normative contribution __ Correction __ New feature __ Addition to obsolescent feature list __ Addition to Future Directions __ Other (please specify) ______________________________ Area of Standard Affected: __ Environment Y_ Language __ Preprocessor __ Library __ Macro/typedef/tag name __ Function __ Header Y_ Other (please specify) Annex_________________________ Prior Art: None.____________________________________________ Target Audience: Programmers writing programs that perform a significant amount of numeric processing.___________________ Related Documents (if any): WG14/N758 C9X and LIA-1 informative annex, WG14/N756 LIA-1 Binding: Arithmetic exception => SIGFPE, WG14/N755 LIA-1 Binding: to , WG14/N753 LIA-1 Binding: Rationale, WG14/N752 LIA-1 Binding: Optional parts annex, WG14/N751 LIA-1 Binding: Combined LIA-1 + IEC-559 annex, WG14/N750 LIA-1 Binding: LIA-1 annex. WG14/N749 LIA-1 Binding: , WG14/N748 LIA-1 Binding: Adding 'pole' from LIA-2, WG14/N747 IEC 559 Binding: Signaling NaNs, WG14/N528 C Binding for LIA-1, WG14/N488 LIA-2 (math library), WG14/N487 LIA-1 (arithmetic), WG14/N486 LIA Overview, WG14/N463 Impact of adding LIA-1, WG14/N461 C Binding of LIA-1, Defect Report 152 longjmp from a signal handler, Defect Report 099 Narrowing of FP expression, Defect Report 056/063 Accuracy of floating-point, Defect Report 036 Representation of FP constants, Defect Report 025 Floating-point representation. Proposal Attached: _Y Yes __ No, but what's your interest? Abstract: This is an informative annex to C9X to document the extent to which the C language currently supports the LIA-1 requirements. It is NOT a binding bewteen C and LIA-1. The other proposals should be considered a starting point of the LIA-1 to C binding (if that binding is wanted). Proposal: Note: The '*' characters in the lefthand column are not part of the proposal (they are useful for emacs M-x outline mode) In the following, bold text, italic text, code sample are the conventions used to indicate text different from normal. * -- Add to Annex A Bibliography: ISO/IEC 10967-1:1994(E) Information technology -- Language independent arithmetic -- Part 1: Integer and floating point arithmetic. * -- Add a new annex, here called H, after annex G IEC 559-compatible complex arithmetic: Annex H (informative) Language independent arithmetic ** H.1 Introduction This annex documents the extent to which the C language supports the standard: ISO/IEC 10967-1 Language independent arithmetic, part 1, integer and floating-point arithmetic (LIA-1). LIA-1 is more general than IEC 559 (annex F) in that it covers integer and diverse floating-point arithmetics. ** H.2 Types The relevant C arithmetic types meet the requirements of LIA-1 types if an implementation adds notification of exceptional arithmetic operations and meets the 1-ULP accuracy requirement. *** H.2.1 Boolean Type The LIA-1 data type Boolean is implemented by the C data type bool with values of true and false, all from . *** H.2.2 Integer Types The signed C integer types int, long, long long and the corresponding unsigned types are compatible with LIA-1. If an implementation adds support for the LIA-1 exceptional values integer_overflow and undefined, then those types are LIA-1 conformant types. C's unsigned integer types are "modulo" in the LIA-1 sense in that overflows or out-of-bounds results silently wrap. An implementation that defines signed integer types as also being modulo need not detect integer overflow, in which case, only integer divide-by-zero need be detected. The parameters for the integer data types can be accessed by the following: maxint INT_MAX, LONG_MAX, LLONG_MAX, UINT_MAX, ULONG_MAX, ULLONG_MAX minint INT_MIN, LONG_MIN, LLONG_MIN The parameter "bounded" is always true, and is not provided. The parameter "minint" is always 0 for the unsigned types, and is not provided for those types. **** H.2.2.2 Integer Operations The integer operations on integer types are the following: addI x + y subI x - y mulI x * y divI, divtI x / y remI, remtI x % y negI - x absI abs(x), labs(x), llabs(x) eqI x == y neqI x != y lssI x < y leqI x <= y gtrI x > y geqI x >= y where x and y are expressions of the same integer type. *** H.2.3 Floating-Point Types The C floating-point types float, double, and long double are compatible with LIA-1. If an implementation adds support for the LIA-1 exceptional values underflow, floating_overflow, and undefined, then those types are conformant with LIA-1. An implementation that uses IEC 559 floating-point formats and operations (see Annex F) along with IEC 559 status flags and traps has LIA-1 conformant types. **** H.2.3.1 Floating-Point Parameters The parameters for a floating point data type can be accessed by the following: r FLT_RADIX p FLT_MANT_DIG, DBL_MANT_DIG, LDBL_MANT_DIG emax FLT_MAX_EXP, DBL_MAX_EXP, LDBL_MAX_EXP emin FLT_MIN_EXP, DBL_MIN_EXP, LDBL_MIN_EXP The derived constants for the floating point types are accessed by the following: fmax FLT_MAX, DBL_MAX, LDBL_MAX fminN FLT_MIN, DBL_MIN, LDBL_MIN epsilon FLT_EPSILON, DBL_EPSILON, LDBL_EPSILON rnd_style FLT_ROUNDS **** H.2.3.2 Floating-Point Operations The floating-point operations on floating-point types are the following: addF x + y subF x - y mulF x * y divF x / y negF - x absF fabsf(x), fabs(x), fabsl(x) exponentF 1.f+logbf(x), 1.0+logb(x), 1.L+logbl(x) scaleF scalbnf(x, n), scalbn(x, n), scalbnl(x, n) scalblnf(x, li), scalbln(x, li), scalblnl(x, li) intpartF modff(x, &y), modf(x, &y), modfl(x, &y) fractpartF modff(x, &y), modf(x, &y), modfl(x, &y) eqF x == y neqF x != y lssF x < y leqF x <= y gtrF x > y geqF x >= y where x and y are expressions of the same floating point type, n is of type int, and li is of type long int. **** H.2.3.3 Rounding Styles The C Standard requires all floating types use the same radix and rounding style, so that only one identifier for each is provided to map to LIA-1. The FLT_ROUNDS parameter can be used to indicate the LIA-1 rounding styles: truncate FLT_ROUNDS == 0 nearest FLT_ROUNDS == 1 other FLT_ROUNDS != 0 && FLT_ROUNDS != 1 provided that an implementation extends FLT_ROUNDS to cover the rounding style used in all relevant LIA-1 operations, not just addition as in C. *** H.2.4 Type Conversions The LIA-1 type conversions are the following type casts: cvtI'->I (int)i, (long)i, (long long)i, (unsigned int)i, (unsigned long)i, (unsigned long long)i cvtF->I (int) x, (long) x, (long long) x, (unsigned int) x, (unsigned long) x, (unsigned long long) x cvtI->F (float) i, (double) i, (long double) i cvtF'->F (float) x, (double) x, (long double) x In the above conversions from floating to integer, the use of (cast)x can be replaced with (cast)round(x), (cast)rint(x) (cast)nearbyint(x), (cast)trunc(x), (cast)ceil(x), or (cast)floor(x) as they all meet LIA's requirements on floating to integer rounding. The remainder() function is useful for doing silent wrapping to unsigned integer types. C's floating-point to integer conversion functions, lrint(), llrint(), lround(), and llround(), can meet LIA-1's requirements if an implementation handles out of range as per LIA-1. C's conversions (type casts) from floating-point to floating-point can meet LIA-1 if an implementation uses round to nearest. C's conversions (type casts) from integer to floating-point can meet LIA-1 if an implementation uses round to nearest. ** H.3 Notification Notification is the process by which a user or program is informed that an exceptional arithmetic operation has occured. C's operations are compatible with LIA-1 in that C allows an implementation to cause a notification to occur when any arithmetic operation returns an exceptional value as defined in LIA-1 clause 5. *** H.3.1 Notification alternatives LIA-1 requires at least the following two alternatives for handling of notifications: setting indicators or trap-and-terminate. LIA-1 allows a third alternative: trap-and-resume. An implementation need only support a given notification alternative for the entire program. An implementation may support the ability to switch between notification alternatives during execution, but is not required to do so. An implementation can provide separate selection for each kind of notification, but this is not required. C allows an implementation to provide notification. C's SIGFPE (for traps) and FE_INVALID, FE_DIVBYZERO, FE_OVERFLOW, FE_UNDERFLOW (for indicators) can provide LIA notification. C's signal handlers are compatible with LIA-1. Default handling of SIGFPE can provide trap-and-terminate behavior. User provided signal handlers for SIGFPE allow for trap-and-resume behavior. **** H.3.1.1 Indicators C's status flags are compatible with LIA's indicators. The following mapping is for floating-point types: undefined FE_INVALID, FE_DIVBYZERO floating_overflow FE_OVERFLOW underflow FE_UNDERFLOW The floating-point indicator interrogation and manipulation operations are: set_indicators feraiseexcept(i) clear_indicators feclearexcept(i) test_indicators fetestexcept(i) current_indicators fetestexcept(FE_ALL_EXCEPT) where i is an expression of type int representing a LIA-1 indicator subset. C allows an implementation to provide the following LIA-1 required behavior: at program termination if any indicator is set the implementation shall send an unambiguous and "hard to ignore" message (see LIA-1 subclause 6.1.2) LIA-1 does not make the distinction between floating-point and integer for undefined. This documentation is making that distinction because covers only the floating-point indicators. **** H.3.1.2 Traps C is compatible with LIA's trap requirements. An implementation can provide an alternative of notification through termination with a ``hard-to-ignore'' message (see LIA-1 subclause 6.1.3). LIA-1 does not require that traps be precise. C does require that SIGFPE be the signal corresponding to arithmetic exceptions, if there is any signal raised for them. C has signal handlers for SIGFPE and allows trapping arithmetic exceptions. When arithmetic exceptions do trap, C's signal-handler mechanism allows trap-and-terminate (either default implementation behavior or user replacement for it) and trap-and-resume, at the programmer's option.