Austin Group AI-2005-01-05 Part 1 - XBD Changes Austin-246 Page 1 of 1 Submitted by Andrew Josey, The Open Group. February 24, 2005 ACTION AI-2005-01-05: AJ to prepare draft document on impact of C99 TC2 on POSIX. Status: OPEN The ISO C99 TC2 document can be freely obtained from: http://webstore.ansi.org/ansidocstore/find.asp?find_spec=9899 PART 1 --- XBD 2004 edition Changes. @ Page 116 Line 3727 Section 6.2 Comment [ISO C TC2 #3] Problem: ISO C TC2 #3 Action: (XBD Section 6.2 Character Encoding) Change from: lines 3727- A byte with all bits zero shall be interpreted as the null character independent of shift state. Thus a byte with all bits zero shall never occur in the second or subsequent bytes of a character. To: A byte with all bits zero shall be interpreted as the null character independent of shift state. Such a byte shall not occur as part of any other character. @ page 229 Line 8083 Section float.h Comment [ISO C TC2 #4] Problem: ISO C TC2 #4 Action: Add a new paragraph after line 8083 in float.h DESCRIPTION An implementation may give zero and non-numeric values, such as inifinities and NaNs, a sign or may leave them unsigned. Wherever such values are unsigned, any requirement in this standard to retrieve the sign shall produce an unspecified sign, and any requirement to set the sign shall be ignored. @ page 229 Line 8084 Section float.h Comment [ISO C TC2 #5] Problem: ISO C TC2 #5 Action: Change from: "The accuracy of the floating-point operations ( '+', '-', '*', '/' ) and of the library functions in and that return floating-point results is implementation-defined. The implementation may state that the accuracy is unknown." To: "The accuracy of the floating-point operations ( '+', '-', '*', '/' ) and of the functions in and that return floating-point results is implementation-defined, as is the accuracy of the conversion between floating-point internal representations and string representations performed by the functions in , , and . The implementation may state that the accuracy is unknown." (Ed note, I took the opportunity to clean up occurrences of library functions to plain functions as we do not distinguish between library functions and system calls, referring to both just as functions). @ page 210 Line 7419 Section complex.h Comment [ISO C TC2 #34] Problem: ISO C TC2 #34 Action: Change From: imaginary Expands to _Imaginary. _Imaginary_I Expands to a constant expression of type const float _Imaginary with the value of the imaginary unit. To: I Expands to _Complex_I [Note from gwc: I think there may be a problem here with C99 (as amended by TC2). As far as I can see there is no longer any mention of the imaginary macro in normative text, which means implementations are not allowed to define it (because it is not reserved for use by the implementation). Yet in Annex G it still recommends (in informative text) that implementations which define __STDC_IEC_559_COMPLEX__ should define the imaginary macro. It also recommends that these implementations should define I "to be _Imaginary_I (not _Complex_I as stated in 7.3)". Yet implementations that do so would not comply with the normative text in 7.3 which requires I to be defined as _Complex_I. Assuming that the intention was to allow implementations to follow the recommendations in Annex G, but by an oversight the necessary normative text to allow them to do so was omitted from TC2, perhaps in POSIX we should keep the current text but mark some of it CX?] @ page 210 Line 7424 Section complex.h Comment [ISO C TC2 #35] Problem: ISO C TC2 #35 Action: Delete the text "I Expands to either _Imaginary_I or _Complex_I. If _Imaginary_I is not defined, I expands to _Complex_I. The macros imaginary and _Imaginary_I shall be defined if and only if the implementation supports imaginary types." @ page 210 Line 7428 Section complex.h Comment [ISO C TC2 #36] Problem: ISO C TC2 #36 Action: Change From: An application may undefine and then, perhaps, redefine the complex, imaginary, and I macros. To: An application may undefine and then, perhaps, redefine the complex, and I macros. @ page 226 Line 7953 Section fenv.h Comment [ISO C TC2 #37] Problem: ISO C TC2 #37 Action: Change from: "The header shall define the following constant, which is simply the bitwise-inclusive OR of all floating-point exception constants defined above: FE_ALL_EXCEPT" To: "The header shall define the constant FE_ALL_EXCEPT as the bitwise-inclusive OR of all floating-point exception constants defined above . If no such constants are defined above then the constant FE_ALL_EXCEPT shall be defined as zero." @ Page 267 Line 9446 Section math.h Comment [ISO C TC2 #47] Problem: ISO C TC2 #47 Action: Change from: If defined, the FP_FAST_FMA macro shall indicate that the fma() function generally executes about as fast as, or faster than, a multiply and an add of double operands. If undefined, the speed of execution is unspecified. The other macros have the equivalent meaning for the float and long double versions. To: If defined, the FP_FAST_FMA macro shall expand to the integer constant 1 and shall indicate that the fma() function generally executes about as fast as, or faster than, a multiply and an add of double operands. If undefined, the speed of execution is unspecified. The other macros have the equivalent meaning for the float and long double versions. @ page 317 Line 11280 Section stddef.h Comment [ISO C TC2 #58] Problem: ISO C TC2 #58 Action: Change from: "wchar_t Integer type whose range of values can represent distinct wide-character codes for all members of the largest character set specified among the locales supported by the compilation environment: the null character has the code value 0 and each member of the portable character set has a code value equal to its value when used as the lone character in an integer character constant." To: "wchar_t Integer type whose range of values can represent distinct wide-character codes for all members of the largest character set specified among the locales supported by the compilation environment: the null character has the code value 0." @ page 47 Line 1601 Section 3.85 Comment [ISO C TC2 #67] Problem: ISO C TC2 #67 (This change adds perror() to the list of byte input/output functions.) Action: Insert perror() into the list of functions.