@ page 139 line 4494 section assert objection [tog-c99-xsh 1] Problem: Change required for alignment with C99 (ref C99 section 7.2.1.1) Action: Change "void assert(int expression);" To "void assert(scalar expression);" @ page 139 line 4499-4503 section assert objection [tog-c99-xsh 2] Problem: Change required for alignment with C99 (ref C99 section 7.2.1.1) Action: Change "The assert( ) macro inserts diagnostics into programs. When it is executed, if expression is false (that is, compares equal to 0), assert( ) writes information about the particular call that failed (including the text of the argument, the name of the source file, and the source file line number—the latter are respectively the values of the preprocessing macros __FILE__ and __LINE__) on stderr and calls abort()." To "The assert( ) macro inserts diagnostics into programs; it exapnds to a void expression. When it is executed, if expression (which shall have a scalar type) is false (that is, compares equal to 0), assert( ) writes information about the particular call that failed (including the text of the argument, the name of the source file, the source file line number, and the name of the enclosing function — the latter are respectively the values of the preprocessing macros __FILE__ and __LINE__ and of the identifier __func__) on stderr and calls abort()." @ page 163 line 5207 section cacos objection [tog-c99-xsh 3] Problem: Change required for alignment with C99 (ref C99 section 7.3.5.1). Action: Add the following entry after line 5207: NAME cacos - complex arc cosine functions SYNOPSIS #include double complex cacos(double complex z); float complex cacosf(float complex z); long double complex cacosl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cacos family of functions shall compute the complex arc cosine of z, with branch cuts outside the interval [-1, +1] along the real axis. RETURN VALUE The cacos family of functions shall return the complex arc cosine value, in the range of a strip mathematically unbounded along the imaginary axis and in the interval [0, pi] along the real axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO ccos(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 165 line 5267 section casin objection [tog-c99-xsh 4] Problem: Change required for alignment with C99 (ref C99 section 7.3.5.2). Action: Add the following entry after line 5267: NAME casin - complex arc sine functions SYNOPSIS #include double complex casin(double complex z); float complex casinf(float complex z); long double complex casinl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The casin family of functions shall compute the complex arc sine of z, with branch cuts outside the interval [-1, +1] along the real axis. RETURN VALUE The casin family of functions shall return the complex arc sine value, in the range of a strip mathematically unbounded along the imaginary axis and in the interval [-pi/2, +pi/2] along the real axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO csin(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 167 line 5267 section catan objection [tog-c99-xsh 5] Problem: Change required for alignment with C99 (ref C99 section 7.3.5.3). Action: Add the following entry after line 5267: NAME catan - complex arc tangent functions SYNOPSIS #include double complex catan(double complex z); float complex catanf(float complex z); long double complex catanl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The catan family of functions shall compute the complex arc tangent of z, with branch cuts outside the interval [-i, +i] along the imaginary axis. RETURN VALUE The catan family of functions shall return the complex arc tangent value, in the range of a strip mathematically unbounded along the imaginary axis and in the interval [-pi/2, +pi/2] along the real axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO ctan(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 171 line 5455 section ccos objection [tog-c99-xsh 6] Problem: Change required for alignment with C99 (ref C99 section 7.3.5.4). Action: Add the following entry after line 5455: NAME ccos - complex cosine functions SYNOPSIS #include double complex ccos(double complex z); float complex ccosf(float complex z); long double complex ccosl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The ccos family of functions shall compute the complex cosine of z. RETURN VALUE The ccos family of functions shall return the complex cosine value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cacos(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 224 line 7140 section csin objection [tog-c99-xsh 7] Problem: Change required for alignment with C99 (ref C99 section 7.3.5.5). Action: Add the following entry after line 7140: NAME csin - complex sine functions SYNOPSIS #include double complex csin(double complex z); float complex csinf(float complex z); long double complex csinl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The csin family of functions shall compute the complex sine of z. RETURN VALUE The csin family of functions shall return the complex sine value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO casin(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 224 line 7140 section ctan objection [tog-c99-xsh 8] Problem: Change required for alignment with C99 (ref C99 section 7.3.5.6). Action: Add the following entry after line 7140: NAME ctan - complex tangent functions SYNOPSIS #include double complex ctan(double complex z); float complex ctanf(float complex z); long double complex ctanl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The ctan family of functions shall compute the complex tangent of z. RETURN VALUE The ctan family of functions shall return the complex tangent value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO catan(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 163 line 5207 section cacosh objection [tog-c99-xsh 9] Problem: Change required for alignment with C99 (ref C99 section 7.3.6.1). Action: Add the following entry after line 5207: NAME cacosh - complex arc hyperbolic cosine functions SYNOPSIS #include double complex cacosh(double complex z); float complex cacoshf(float complex z); long double complex cacoshl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cacosh family of functions shall compute the complex arc hyperbolic cosine of z, with a branch cut at values less than 1 along the real axis. RETURN VALUE The cacosh family of functions shall return the complex arc hyperbolic cosine value, in the range of a half-strip of non-negative values along the real axis and in the interval [-ipi, +ipi] along the imaginary axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO ccosh(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 224 line 7140 section casinh objection [tog-c99-xsh 10] Problem: Change required for alignment with C99 (ref C99 section 7.3.6.2). Action: Add the following entry after line 7140: NAME casinh - complex arc hyperbolic sine functions SYNOPSIS #include double complex casinh(double complex z); float complex casinhf(float complex z); long double complex casinhl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The casinh family of functions shall compute the complex arc hyperbolic sine of z, with branch cuts outside the interval [-i, +i] along the imaginary axis. RETURN VALUE The casinh family offunctions shall return the complex arc hyperbolic sine value, in the range of a strip mathematically unbounded along the real axis and in the interval [-ipi/2, +ipi/2] along the imaginary axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO csinh(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 167 line 5267 section catanh objection [tog-c99-xsh 11] Problem: Change required for alignment with C99 (ref C99 section 7.3.6.3). Action: Add the following entry after line 5267: NAME catanh - complex arc hyperbolic tangent functions SYNOPSIS #include double complex catanh(double complex z); float complex catanhf(float complex z); long double complex catanhl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The catanh family of functions shall compute the complex arc hyperbolic tangent of z, with branch cuts outside the interval [-1, +1] along the real axis. RETURN VALUE The catanh family of functions shall return the complex arc hyperbolic tangent value, in the range of a strip mathematically unbounded along the real axis and in the interval [-ipi/2, +ipi/2] along the imaginary axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO ctanh(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 171 line 5455 section ccosh objection [tog-c99-xsh 12] Problem: Change required for alignment with C99 (ref C99 section 7.3.6.4). Action: Add the following entry after line 5455: NAME ccosh - complex hyperbolic cosine functions SYNOPSIS #include double complex ccosh(double complex z); float complex ccoshf(float complex z); long double complex ccoshl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The ccosh family of functions shall compute the complex hyperbolic cosine of z. RETURN VALUE The ccosh family of functions shall return the complex hyperbolic cosine value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cacosh(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 224 line 7140 section csinh objection [tog-c99-xsh 13] Problem: Change required for alignment with C99 (ref C99 section 7.3.6.5). Action: Add the following entry after line 7140: NAME csinh - complex hyperbolic sine functions SYNOPSIS #include double complex csinh(double complex z); float complex csinhf(float complex z); long double complex csinhl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The csinh family of functions shall compute the complex hyperbolic sine of z. RETURN VALUE The csinh family of functions shall return the complex hyperbolic sine value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO casinh(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 224 line 7140 section ctanh objection [tog-c99-xsh 14] Problem: Change required for alignment with C99 (ref C99 section 7.3.6.6). Action: Add the following entry after line 7140: NAME ctanh - complex hyperbolic tangent functions SYNOPSIS #include double complex ctanh(double complex z); float complex ctanhf(float complex z); long double complex ctanhl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The ctanh family of functions shall compute the complex hyperbolic tangent of z. RETURN VALUE The ctanh family of functions shall return the complex hyperbolic tangent value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO catanh(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 173 line 5506 section cexp objection [tog-c99-xsh 15] Problem: Change required for alignment with C99 (ref C99 section 7.3.7.1). Action: Add the following entry after line 5506: NAME cexp - complex exponential functions SYNOPSIS #include double complex cexp(double complex z); float complex cexpf(float complex z); long double complex cexpl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cexp family of functions shall compute the complex base-e exponential of z. RETURN VALUE The cexp family of functions shall return the complex base-e exponential value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO clog(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 201 line 6394 section clog objection [tog-c99-xsh 16] Problem: Change required for alignment with C99 (ref C99 section 7.3.7.2). Action: Add the following entry after line 6394: NAME clog - complex natural logarithm functions SYNOPSIS #include double complex clog(double complex z); float complex clogf(float complex z); long double complex clogl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The clog family of functions shall compute the complex natural (base-e) logarithm of z, with a branch cut along the negative real axis. RETURN VALUE The clog family of functions shall return the complex natural logarithm value, in the range of a strip mathematically unbounded along the real axis and in the interval [-ipi, +ipi] along the imaginary axis. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cexp(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 220 line 7005 section cpow objection [tog-c99-xsh 17] Problem: Change required for alignment with C99 (ref C99 section 7.3.8.2). Action: Add the following entry after line 7005: NAME cpow - complex power functions SYNOPSIS #include double complex cpow(double complex x, double complex y); float complex cpowf(float complex x, float complex y); long double complex cpowl(long double complex x, long double complex y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cpow family of functions shall compute the complex power function x**y, with a branch cut for the first parameter along the negative real axis. RETURN VALUE The cpow family of functions shall return the complex power function value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cabs(), csqrt(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 224 line 7140 section csqrt objection [tog-c99-xsh 18] Problem: Change required for alignment with C99 (ref C99 section 7.3.8.3). Action: Add the following entry after line 7140: NAME csqrt - complex square root functions SYNOPSIS #include double complex csqrt(double complex z); float complex csqrtf(float complex z); long double complex csqrtl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The csqrt family of functions shall compute the complex square root of z, with a branch cut along the negative real axis. RETURN VALUE The csqrt family of functions shall return the complex square root value, in the range of the right half-plane (including the imaginary axis). ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cabs(), cpow(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 165 line 5267 section carg objection [tog-c99-xsh 19] Problem: Change required for alignment with C99 (ref C99 section 7.3.9.1). Action: Add the following entry after line 5267: NAME carg - complex argument functions SYNOPSIS #include double carg(double complex z); float cargf(float complex z); long double cargl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The carg family of functions shall compute the argument (also called phase angle) of z, with a branch cut along the negative real axis. RETURN VALUE The carg family of functions shall return the value of the argument in the interval [-pi, +pi]. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO cimag(), conj(), cproj(), creal(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 191 line 6052 section cimag objection [tog-c99-xsh 20] Problem: Change required for alignment with C99 (ref C99 section 7.3.9.2). Action: Add the following entry after line 6052: NAME cimag - complex imaginary functions SYNOPSIS #include double cimag(double complex z); float cimagf(float complex z); long double cimagl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cimag family of functions shall compute the imaginary part of z. RETURN VALUE The cimag family of functions shall return the imaginary part value (as a real). ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE For a variable z of complex type, z == creal(z) + cimag(z)*I. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO carg(), conj(), cproj(), creal(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 213 line 6801 section conj objection [tog-c99-xsh 21] Problem: Change required for alignment with C99 (ref C99 section 7.3.9.3). Action: Add the following entry after line 6801: NAME conj - complex conjugate functions SYNOPSIS #include double complex conj(double complex z); float complex conjf(float complex z); long double complex conjl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The conj family of functions compute the complex conjugate of z, by reversing the sign of its imaginary part. RETURN VALUE The conj family of functions return the complex conjugate value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO carg(), cimag(), cproj(), creal(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 220 line 7005 section cproj objection [tog-c99-xsh 22] Problem: Change required for alignment with C99 (ref C99 section 7.3.9.4). Action: Add the following entry after line 7005: NAME cproj - complex projection functions SYNOPSIS #include double complex cproj(double complex z); float complex cprojf(float complex z); long double complex cprojl(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cproj family of functions shall compute a projection of z onto the Riemann sphere: z projects to z except that all complex infinities (even those with one infinite part and one NaN part) project to positive infinity on the real axis. If z has an infinite part, then cproj(z) is equivalent to INFINITY + I * copysign(0.0, cimag(z)) RETURN VALUE The cproj family of functions shall return the value of the projection onto the Riemann sphere. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE Two topologies are commonly used in complex mathematics: the complex plane with its continuum of infinities, and the Riemann sphere with its single infinity. The complex plane is better suited for transcendental functions, the Riemann sphere for algebraic functions. The complex types with their multiplicity of infinities provide a useful (though imperfect) model for the complex plane. The cproj function helps model the Riemann sphere by mapping all infinities to one, and should be used just before any operation, especially comparisons, that might give spurious results for any of the other infinities. Note that a complex value with one infinite part and one NaN part is regarded as an infinity, not a NaN, because if one part is infinite, the complex value is infinite independent of the value of the other part. For the same reason, cabs returns an infinity if its argument has an infinite part and a NaN part. FUTURE DIRECTIONS None. SEE ALSO carg(), cimag(), conj(), creal(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 220 line 7005 section creal objection [tog-c99-xsh 23] Problem: Change required for alignment with C99 (ref C99 section 7.3.9.5). Action: Add the following entry after line 7005: NAME creal - complex real functions SYNOPSIS #include double creal(double complex z); float crealf(float complex z); long double creall(long double complex z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The creal family of functions shall compute the real part of z. RETURN VALUE The creal family of functions shall return the real part value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE For a variable z of complex type, z == creal(z) + cimag(z)*I. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO carg(), cimag(), conj(), cproj(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 609 line 19313 section isblank objection [tog-c99-xsh 24] Problem: Change required for alignment with C99 (ref C99 section 7.4.1.3). Action: Add the following entry after line 19313: NAME isblank - test for a blank character SYNOPSIS #include int isblank(int c); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isblank( ) function shall test whether c is a character of class blank in the program's current locale; see the System Interface Definitions volume of IEEE Std. 1003.1-200x, Chapter 7, Locale. In all cases c is a type int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined. RETURN VALUE The isblank( ) function shall return non-zero if c is a blank character; otherwise, it shall return 0. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE To ensure applications portability, especially across natural languages, only this function and those listed in the SEE ALSO section should be used for character classification. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isalnum(), isalpha (), iscntrl(), isdigit (), isgraph(), islower(), isprint(), ispunct(), isspace(), isupper(), isxdigit (), setlocale ( ), the System Interface Definitions volume of IEEE Std. 1003.1-200x, , the System Interface Definitions volume of IEEE Std. 1003.1-200x, Chapter 7, Locale CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 321 line 10199 section feclearexcept objection [tog-c99-xsh 25] Problem: Change required for alignment with C99 (ref C99 section 7.6.2.1). Action: Add the following entry after line 10199: NAME feclearexcept - clear floating-point exception SYNOPSIS #include void feclearexcept(int excepts); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The feclearexcept() function shall clear the supported floating-point exceptions represented by excepts. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fegetexceptflag(), feraiseexcept(), fesetexceptflag(), fetestexcept(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 321 line 10199 section fegetexceptflag objection [tog-c99-xsh 26] Problem: Change required for alignment with C99 (ref C99 section 7.6.2.2). Action: Add the following entry after line 10199: NAME fegetexceptflag - get floating-point status flags SYNOPSIS #include void fegetexceptflag(fexcept_t *flagp, int excepts); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fegetexceptflag() function shall store an implementation-dependent representation of the states of the floating-point status flags indicated by the argument excepts in the object pointed to by the argument flagp. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO feclearexcept(), feraiseexcept(), fesetexceptflag(), fetestexcept(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 322 line 10230 section feraiseexcept objection [tog-c99-xsh 27] Problem: Change required for alignment with C99 (ref C99 section 7.6.2.3). Action: Add the following entry after line 10230: NAME feraiseexcept - raise floating-point exception SYNOPSIS #include void feraiseexcept(int excepts); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The feraiseexcept() function shall raise the supported floating-point exceptions represented by its argument. The order in which these floating-point exceptions are raised is unspecified. Whether the feraiseexcept() function additionally raises the inexact floating-point exception whenever it raises the overflow or underflow floating-point exception is implementation-dependent. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The effect is intended to be similar to that of floating-point exceptions raised by arithmetic operations. Hence, enabled traps for floating-point exceptions raised by this function are taken. RATIONALE Raising overflow or underflow is allowed to also raise inexact because on some architectures the only practical way to raise an exception is to execute an instruction that has the exception as a side effect. Any IEC 60559 operation that raises either overflow or underflow raises inexact as well. The function is not restricted to accept only valid coincident expressions for atomic operations, so the function can be used to raise exceptions accrued over several operations. FUTURE DIRECTIONS None. SEE ALSO feclearexcept(), fegetexceptflag(), fesetexceptflag(), fetestexcept(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 323 line 10261 section fesetexceptflag objection [tog-c99-xsh 28] Problem: Change required for alignment with C99 (ref C99 section 7.6.2.4). Action: Add the following entry after line 10261: NAME fesetexceptflag - set floating-point status flags SYNOPSIS #include void fesetexceptflag(const fexcept_t *flagp, int excepts); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fesetexceptflag() function shall set the floating-point status flags indicated by the argument excepts to the states stored in the object pointed to by flagp. The value of *flagp shall have been set by a previous call to fegetexceptflag() whose second argument represented at least those floating-point exceptions represented by the argument excepts. This function does not raise floating-point exceptions, but only sets the state of the flags. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO feclearexcept(), fegetexceptflag(), feraiseexcept(), fetestexcept(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 323 line 10261 section fetestexcept objection [tog-c99-xsh 29] Problem: Change required for alignment with C99 (ref C99 section 7.6.2.5). Action: Add the following entry after line 10261: NAME fetestexcept - test floating-point exception flags SYNOPSIS #include int fetestexcept(int excepts); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fetestexcept() function shall determine which of a specified subset of the floating-point exception flags are currently set. The excepts argument specifies the floating-point status flags to be queried. RETURN VALUE The fetestexcept() function shall return the value of the bitwise OR of the floating-point exception macros corresponding to the currently set floating-point exceptions included in excepts. ERRORS No errors are defined. EXAMPLES Call f if invalid is set, then g if overflow is set: #include /* ... */ { #pragma STDC FENV_ACCESS ON int set_excepts; feclearexcept(FE_INVALID | FE_OVERFLOW); // maybe raise exceptions set_excepts = fetestexcept(FE_INVALID | FE_OVERFLOW); if (set_excepts & FE_INVALID) f(); if (set_excepts & FE_OVERFLOW) g(); /* ... */ } APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO feclearexcept(), fegetexceptflag(), feraiseexcept(), fesetexceptflag(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 321 line 10119 section fegetround objection [tog-c99-xsh 30] Problem: Change required for alignment with C99 (ref C99 section 7.6.3.1). Action: Add the following entry after line 10119: NAME fegetround - get current rounding direction SYNOPSIS #include int fegetround(void); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fegetround() function shall get the current rounding direction. RETURN VALUE The fegetround() function shall return the value of the rounding direction macro representing the current rounding direction or a negative value if there is no such rounding direction macro or the current rounding direction is not determinable. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fesetround(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 323 line 10261 section fesetround objection [tog-c99-xsh 31] Problem: Change required for alignment with C99 (ref C99 section 7.6.3.2). Action: Add the following entry after line 10261: NAME fesetround - set current rounding direction SYNOPSIS #include int fesetround(int round); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fesetround() function shall establishe the rounding direction represented by its argument round. If the argument is not equal to the value of a rounding direction macro, the rounding direction is not changed. RETURN VALUE The fesetround() function shall return a zero value if and only if the argument is equal to a rounding direction macro (that is, if and only if the requested rounding direction was established). ERRORS No errors are defined. EXAMPLES Save, set, and restore the rounding direction. Report an error and abort if setting the rounding direction fails. #include #include void f(int round_dir) { #pragma STDC FENV_ACCESS ON int save_round; int setround_ok; save_round = fegetround(); setround_ok = fesetround(round_dir); assert(setround_ok == 0); /* ... */ fesetround(save_round); /* ... */ } APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fegetround(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 321 line 10119 section fegetenv objection [tog-c99-xsh 32] Problem: Change required for alignment with C99 (ref C99 section 7.6.4.1). Action: Add the following entry after line 10119: NAME fegetenv - get current floating-point environment SYNOPSIS #include void fegetenv(fenv_t *envp); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fegetenv() function shall store the current floating-point environment in the object pointed to by envp. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO feholdexcept(), fesetenv(), feupdateenv(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 321 line 10119 section feholdexcept objection [tog-c99-xsh 33] Problem: Change required for alignment with C99 (ref C99 section 7.6.4.2). Action: Add the following entry after line 10119: NAME feholdexcept - save current floating-point environment SYNOPSIS #include int feholdexcept(fenv_t *envp); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The feholdexcept() function shall save the current floating-point environment in the object pointed to by envp, clear the floating-point status flags, and then install a non-stop (continue on floating-point exceptions) mode, if available, for all floating-point exceptions. RETURN VALUE The feholdexcept() function shall return zero if and only if non-stop floating-point exception handling was successfully installed. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE feholdexcept should be effective on typical IEC 60559 implementations which have the default non-stop mode and at least one other mode for trap handling or aborting. If the implementation provides only the non-stop mode, then installing the non-stop mode is trivial. FUTURE DIRECTIONS None. SEE ALSO fegetenv(), fesetenv(), feupdateenv(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 322 line 10230 section fesetenv objection [tog-c99-xsh 34] Problem: Change required for alignment with C99 (ref C99 section 7.6.4.3). Action: Add the following entry after line 10230: NAME fesetenv - set floating-point environment SYNOPSIS #include void fesetenv(const fenv_t *envp); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fesetenv() function shall establish the floating-point environment represented by the object pointed to by envp. The argument envp shall point to an object set by a call to fegetenv() or feholdexcept(), or equal a floating-point environment macro. Note that fesetenv() merely installs the state of the floating-point status flags represented through its argument, and does not raise these floating-point exceptions. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fegetenv(), feholdexcept(), feupdateenv(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 322 line 10230 section feupdateenv objection [tog-c99-xsh 35] Problem: Change required for alignment with C99 (ref C99 section 7.6.4.4). Action: Add the following entry after line 10230: NAME feupdateenv - update floating-point environment SYNOPSIS #include void feupdateenv(const fenv_t *envp); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The feupdateenv() function shall save the currently raised floating-point exceptions in its automatic storage, install the floating-point environment represented by the object pointed to by envp, and then raise the saved floating-point exceptions. The argument envp shall point to an object set by a call to feholdexcept() or fegetenv(), or equal a floating-point environment macro. RETURN VALUE None. ERRORS No errors are defined. EXAMPLES Hide spurious underflow floating-point exceptions: #include double f(double x) { #pragma STDC FENV_ACCESS ON double result; fenv_t save_env; feholdexcept(&save_env); // compute result if (/* test spurious underflow */) feclearexcept(FE_UNDERFLOW); feupdateenv(&save_env); return result; } APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fegetenv(), feholdexcept(), fesetenv(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 577 line 18274 section imaxabs objection [tog-c99-xsh 36] Problem: Change required for alignment with C99 (ref C99 section 7.8.2.1). Action: Add the following entry after line 18274: NAME imaxabs - return absolute value SYNOPSIS #include intmax_t imaxabs(intmax_t j); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The imaxabs() function shall compute the absolute value of an integer j. If the result cannot be represented, the behavior is undefined. RETURN VALUE The imaxabs() function shall return the absolute value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The absolute value of the most negative number cannot be represented in two's complement. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO imaxdiv(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 577 line 18274 section imaxdiv objection [tog-c99-xsh 37] Problem: Change required for alignment with C99 (ref C99 section 7.8.2.2). Action: Add the following entry after line 18274: NAME imaxdiv - return quotient and remainder SYNOPSIS #include imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The imaxdiv() function shall compute numer / denom and numer % denom in a single operation. RETURN VALUE The imaxdiv() function shall return a structure of type imaxdiv_t comprising both the quotient and the remainder. The structure shall contain (in either order) the members quot (the quotient) and rem (the remainder), each of which has type intmax_t. If either part of the result cannot be represented, the behavior is undefined. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO imaxabs(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 1350 line 40976 section strtoimax objection [tog-c99-xsh 38] Problem: Change required for alignment with C99 (ref C99 section 7.8.2.3). Action: Add the following entry after line 40976: NAME strtoimax, strtoumax - convert string to integer type SYNOPSIS #include intmax_t strtoimax(const char * restrict nptr, char ** restrict endptr, int base); uintmax_t strtoumax(const char * restrict nptr, char ** restrict endptr, int base); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The strtoimax() and strtoumax() functions shall be equivalent to the strtol(), strtoll(), strtoul(), and strtoull() functions, except that the initial portion of the string shall be converted to intmax_t and uintmax_t representation, respectively. RETURN VALUE The strtoimax() and strtoumax() functions shall return the converted value, if any. If no conversion could be performed, zero shall be returned. If the correct value is outside the range of representable values, INTMAX_MAX, INTMAX_MIN,or UINTMAX_MAX shall be returned (according to the return type and sign of the value, if any), and errno set to [ERANGE}. ERRORS The strtoimax() and strtoumax() functions shall fail if: [ERANGE] The value to be returned is not representable. The strtoimax() and strtoumax() functions may fail if: [EINVAL] The value of base is not supported. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO strtol(), strtoll(), strtoul(), strtoull(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 1509 line 45882 section wcstoimax objection [tog-c99-xsh 39] Problem: Change required for alignment with C99 (ref C99 section 7.8.2.4). Action: Add the following entry after line 45882: NAME wcstoimax, wcstoumax - convert wide-character string to integer type SYNOPSIS #include #include intmax_t wcstoimax(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); uintmax_t wcstoumax(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The wcstoimax() and wcstoumax() functions shall be equivalent to the wcstol(), wcstoll(), wcstoul(), and wcstoull() functions except that the initial portion of the wide string shall be converted to intmax_t and uintmax_t representation, respectively. RETURN VALUE The wcstoimax() function shall return the converted value, if any. If no conversion could be performed, zero shall be returned. If the correct value is outside the range of representable values, INTMAX_MAX, INTMAX_MIN,or UINTMAX_MAX shall be returned (according to the return type and sign of the value, if any), and errno is set to [ERANGE]. ERRORS The wcstoimax() and wcstoumax() functions shall fail if: [EINVAL] The value of base is not supported. [ERANGE] The value to be returned is not representable. The wcstoimax() and wcstoumax() functions may fail if: [EINVAL] No conversion could be performed. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO wcstol(), wcstoll(), wcstoul(), wcstoull(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 672 line 21131 section localeconv objection [tog-c99-xsh 40] Problem: Change required for alignment with C99 (ref C99 section 7.11.2.1). Action: Add after line 21131 [Note. This table needs sorting]: char int_p_cs_precedes Set to 1 or 0 if the int_currency_symbol respectively precedes or succeeds the value for a nonnegative internationally formatted monetary quantity. char int_n_cs_precedes Set to 1 or 0 if the int_currency_symbol respectively precedes or succeeds the value for a negative internationally formatted monetary quantity. char int_p_sep_by_space Set to a value indicating the separation of the int_currency_symbol, the sign string, and the value for a nonnegative internationally formatted monetary quantity. char int_n_sep_by_space Set to a value indicating the separation of the int_currency_symbol, the sign string, and the value for a negative internationally formatted monetary quantity. char int_p_sign_posn Set to a value indicating the positioning of the positive_sign for a nonnegative internationally formatted monetary quantity. char int_n_sign_posn Set to a value indicating the positioning of the negative_sign for a negative internationally formatted monetary quantity. @ page 672 line 21137 section localeconv objection [tog-c99-xsh 41] Problem: Change required for alignment with C99 (ref C99 section 7.11.2.1). Action: Add after line 21137: The values of p_sep_by_space, n_sep_by_space, int_p_sep_by_space, and int_n_sep_by_space are interpreted according to the following: 0 No space separates the currency symbol and value. 1 If the currency symbol and sign string are adjacent, a space separates them from the value; otherwise, a space separates the currency symbol from the value. 2 If the currency symbol and sign string are adjacent, a space separates them; otherwise, a space separates the sign string from the value. @ page 672 line 21138 section localeconv objection [tog-c99-xsh 42] Problem: Change required for alignment with C99 (ref C99 section 7.11.2.1). Action: Change "The values of p_sign_posn and n_sign_posn are interpreted according to the following: To "The values of p_sign_posn, n_sign_posn, int_p_sign_posn, and int_n_sign_posn are interpreted according to the following:" @ page 673 line 21182 section localeconv objection [tog-c99-xsh 43] Problem: Change required for alignment with C99 (ref C99 section 7.11.2.1). Action: Add after line 21182: int_p_cs_precedes 1 1 1 1 int_n_cs_precedes 1 1 1 1 int_p_sep_by_space 0 0 0 0 int_n_sep_by_space 0 0 0 0 int_p_sign_posn 1 1 1 1 int_n_sign_posn 1 4 4 2 @ page 364 line 11588 section fpclassify objection [tog-c99-xsh 44] Problem: Change required for alignment with C99 (ref C99 section 7.12.3.1). Action: Add the following entry after line 11588: NAME fpclassify - classify real floating type SYNOPSIS #include int fpclassify(real-floating x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fpclassify() macro shall classify its argument value as NaN, infinite, normal, subnormal, zero, or into another implementation-dependent category. First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then classification is based on the type of the argument. RETURN VALUE The fpclassify() macro shall return the value of the number classification macro appropriate to the value of its argument. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isfinite(), isinf(), isnan(), isnormal(), signbit(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 612 line 19425 section isfinite objection [tog-c99-xsh 45] Problem: Change required for alignment with C99 (ref C99 section 7.12.3.2). Action: Add the following entry after line 11588: NAME isfinite - test for finite value SYNOPSIS #include int isfinite(real-floating x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isfinite() macro shall determine whether its argument has a finite value (zero, subnormal, or normal, and not infinite or NaN). First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then determination is based on the type of the argument. RETURN VALUE The isfinite() macro shall return a nonzero value if and only if its argument has a finite value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isinf(), isnan(), isnormal(), signbit(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 613 line 19466 section isinf objection [tog-c99-xsh 46] Problem: Change required for alignment with C99 (ref C99 section 7.12.3.3). Action: Add the following entry after line 11588: NAME isinf - test for infinity SYNOPSIS #include int isinf(real-floating x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isinf() macro shall determine whether its argument value is an infinity (positive or negative). First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then determination is based on the type of the argument. RETURN VALUE The isinf() macro shall return a nonzero value if and only if its argument has an infinite value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isfinite(), isnan(), isnormal(), signbit(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 615 line 19527-19556 section isnan objection [tog-c99-xsh 47] Problem: Change required for alignment with C99 (ref C99 section 7.12.3.4). Action: Change lines 19527-19556 to the following: NAME isnan - test for a NaN SYNOPSIS #include int isnan(real-floating x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isnan() macro shall determine whether its argument value is a NaN. First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then determination is based on the type of the argument. RETURN VALUE The isnan() macro shall return a nonzero value if and only if its argument has a NaN value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isfinite(), isinf(), isnormal(), signbit(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 3. Issue 4 The words not supporting NaN are added to the APPLICATION USAGE section. Issue 5 The DESCRIPTION is updated to indicate the return value when NaN is not supported. This text was previously published in the APPLICATION USAGE section. Issue 6. Issue 6 Entry re-written for alignment with C99. @ page 616 line 19556 section isnormal objection [tog-c99-xsh 48] Problem: Change required for alignment with C99 (ref C99 section 7.12.3.5). Action: Add the following entry after line 19556: NAME isnormal - test for a normal value SYNOPSIS #include int isnormal(real-floating x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isnormal() macro shall determine whether its argument value is normal (neither zero, subnormal, infinite, nor NaN). First, an argument represented in a format wider than its semantic type is converted to its semantic type. Then determination is based on the type of the argument. RETURN VALUE The isnormal() macro shall return a nonzero value if and only if its argument has a normal value. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isfinite(), isinf(), isnan(), signbit(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 1268 line 38577 section signbit objection [tog-c99-xsh 49] Problem: Change required for alignment with C99 (ref C99 section 7.12.3.6). Action: Add the following entry after line 38577: NAME signbit - test sign SYNOPSIS #include int signbit(real-floating x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The signbit() macro shall determine whether the sign of its argument value is negative. RETURN VALUE The signbit() macro shall return a nonzero value if and only if the sign of its argument value is negative. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fpclassify(), isfinite(), isinf(), isnan(), isnormal(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 113 line 3753 section acos objection [tog-c99-xsh 50] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.1). Action: Add after line 3753: float acosf(float x); long double acosl(long double x); @ page 113 line 3758 section acos objection [tog-c99-xsh 51] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.1). Action: Change "The acos( ) function ..." To "The acos family of functions ..." Same change on lines 3770 and 3772. @ page 113 line 3763 section acos objection [tog-c99-xsh 52] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.1). Action: Change "Upon successful completion, acos( ) ..." To "Upon successful completion, the acos family of functions ..." @ page 136 line 4437 section asin objection [tog-c99-xsh 53] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.2). Action: Add after line 4437: float asinf(float x); long double asinl(long double x); @ page 136 line 4442 section asin objection [tog-c99-xsh 54] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.2). Action: Change "The asin( ) function ..." To "The asin family of functions ..." Same change on lines 4455 and 4457. @ page 136 line 4447 section asin objection [tog-c99-xsh 55] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.2). Action: Change "Upon successful completion, asin( ) ..." To "Upon successful completion, the asin family of functions ..." @ page 140 line 4530 section atan objection [tog-c99-xsh 56] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.3). Action: Add after line 4530: float atanf(float x); long double atanl(long double x); @ page 140 line 4535 section atan objection [tog-c99-xsh 57] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.3). Action: Change "The atan( ) function ..." To "The atan family of functions ..." Same change on line 4544. @ page 140 line 4539 section atan objection [tog-c99-xsh 58] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.3). Action: Change "Upon successful completion, atan( ) ..." To "Upon successful completion, the atan family of functions ..." @ page 142 line 4574 section atan2 objection [tog-c99-xsh 59] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.4). Action: Add after line 4574: float atan2f(float y, float x); long double atan2l(long double y, long double x); @ page 142 line 4579 section atan2 objection [tog-c99-xsh 60] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.4). Action: Change "The atan2( ) function ..." To "The atan2 family of functions ..." Same change on line 4590. @ page 142 line 4584 section atan2 objection [tog-c99-xsh 61] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.4). Action: Change "Upon successful completion, atan2( ) ..." To "Upon successful completion, the atan family of functions ..." @ page 217 line 6915 section cos objection [tog-c99-xsh 62] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.5). Action: Add after line 6915: float cosf(float x); long double cosl(long double x); @ page 217 line 6920 section cos objection [tog-c99-xsh 63] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.5). Action: Change "The cos( ) function ..." To "The cos family of functions ..." Same change on line 6930. @ page 217 line 6924 section cos objection [tog-c99-xsh 64] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.5). Action: Change "Upon successful completion, cos( ) ..." To "Upon successful completion, the cos family of functions ..." @ page 1286 line 39047 section sin objection [tog-c99-xsh 65] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.6). Action: Add after line 39047: float sinf(float x); long double sinl(long double x); @ page 1286 line 39052 section sin objection [tog-c99-xsh 66] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.6). Action: Change "The sin( ) function ..." To "The sin family of functions ..." Same change on line 39064. @ page 1286 line 39057 section sin objection [tog-c99-xsh 67] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.6). Action: Change "Upon successful completion, sin( ) ..." To "Upon successful completion, the sin family of functions ..." @ page 1382 line 42008 section tan objection [tog-c99-xsh 68] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.7). Action: Add after line 42008: float tanf(float x); long double tanl(long double x); @ page 1382 line 42013 section tan objection [tog-c99-xsh 69] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.7). Action: Change "The tan( ) function ..." To "The tan family of functions ..." Same change on lines 42027 and 42029. @ page 1382 line 42018 section tan objection [tog-c99-xsh 70] Problem: Change required for alignment with C99 (ref C99 section 7.12.4.7). Action: Change "Upon successful completion, tan( ) ..." To "Upon successful completion, the tan family of functions ..." @ page 115 line 3800-3802 section acosh objection [tog-c99-xsh 71] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.1-3). Action: Change "double acosh(double x); double asinh(double x); double atanh(double x);" To "double acosh(double x); float acoshf(float x); long double acoshl(long double x); double asinh(double x); float asinhf(float x); long double asinhl(long double x); double atanh(double x); float atanhf(float x); long double atanhl(long double x);" @ page 115 line 3810 section acosh objection [tog-c99-xsh 72] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.1). Action: Change "The acosh( ) function ..." To "The acosh family functions ..." @ page 115 line 3812 section acosh objection [tog-c99-xsh 73] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.3). Action: Change "The atanh( ) function ..." To "The atanh family of functions ..." @ page 115 line 3817 section acosh objection [tog-c99-xsh 74] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.1). Action: Change "The acosh( ) function ..." To "The acosh family of functions ..." @ page 115 line 3819 section acosh objection [tog-c99-xsh 75] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.3). Action: Change "The atanh( ) function ..." To "The atanh family of functions ..." @ page 115 line 3821 section acosh objection [tog-c99-xsh 76] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.3). Action: Change "The atanh( ) function ..." To "The atanh family of functions ..." @ page 219 line 6966 section cosh objection [tog-c99-xsh 77] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.4). Action: Add after line 6966: float coshf(float x); long double coshl(long double x); @ page 219 line 6971 section cosh objection [tog-c99-xsh 78] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.4). Action: Change "The cosh( ) function ..." To "The cosh family of functions ..." Same change on lines 6979 and 6981. @ page 219 line 6975 section cosh objection [tog-c99-xsh 79] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.4). Action: Change "Upon successful completion, cosh( ) ..." To "Upon successful completion, the cosh family of functions ..." @ page 1288 line 39099 section sinh objection [tog-c99-xsh 80] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.5). Action: Add after line 39099: float sinhf(float x); long double sinhl(long double x); @ page 1288 line 39104 section sinh objection [tog-c99-xsh 81] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.5). Action: Change "The sinh( ) function ..." To "The sinh family of functions ..." Same change on lines 39114 and 39116. @ page 1288 line 39108 section sinh objection [tog-c99-xsh 82] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.5). Action: Change "Upon successful completion, sinh( ) ..." To "Upon successful completion, the sinh family of functions ..." @ page 1384 line 42064 section tanh objection [tog-c99-xsh 83] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.6). Action: Add after line 42064: float tanhf(float x); long double tanhl(long double x); @ page 1384 line 42069 section tanh objection [tog-c99-xsh 84] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.6). Action: Change "The tanh( ) function ..." To "The tanh family of functions ..." Same change on line 42078. @ page 1384 line 42073 section tanh objection [tog-c99-xsh 85] Problem: Change required for alignment with C99 (ref C99 section 7.12.5.6). Action: Change "Upon successful completion, tanh( ) ..." To "Upon successful completion, the tanh family of functions ..." @ page 293 line 9288 section exp objection [tog-c99-xsh 86] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.1). Action: Add after line 9288: float expf(float x); long double expl(long double x); @ page 293 line 9293 section exp objection [tog-c99-xsh 87] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.1). Action: Change "The exp( ) function ..." To "The exp family of functions ..." Same change on lines 9303 and 9305. @ page 293 line 9297 section exp objection [tog-c99-xsh 88] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.1). Action: Change "Upon successful completion, exp( ) ..." To "Upon successful completion, the exp family of functions ..." @ page 294 line 9329 section exp2 objection [tog-c99-xsh 89] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.2). Action: Add the following entry after line 9329: NAME exp2 - exponential base-2 functions SYNOPSIS #include double exp2(double x); float exp2f(float x); long double exp2l(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The exp2 family of functions shall compute the base-2 exponential of x. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE Upon successful completion, the exp2 family of functions shall return 2**x. If the correct value would cause overflow, the exp2 family of functions shall return HUGE_VAL and set errno to [ERANGE]. If the correct value would cause underflow, the exp2 family of functions shall return 0 and may set errno to [ERANGE]. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The exp2 family of functions shall fail if: [ERANGE] The result overflows. The exp2 family of functions may fail if: [EDOM] The value of x is NaN. [ERANGE] The result underflows No other errors shall occur. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO exp(), isnan(), log(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 295 line 9335 section expm1 objection [tog-c99-xsh 90] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.3). Action: Add after line 9335: float expm1f(float x); long double expm1l(long double x); @ page 295 line 9337 section expm1 objection [tog-c99-xsh 91] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.3). Action: Change "The expm1( ) function ..." To "The expm1 family of functions ..." Same change on line 9344. @ page 295 line 9339-9342 section expm1 objection [tog-c99-xsh 92] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.3). Action: Change lines 9339-9342 to: If x is NaN, then the expm1 family of functions shall return NaN and errno may be set to [EDOM]. If x is positive infinity, the expm1 family of functions shall return positive infinity. If x is negative infinity, the expm1 family of functions shall return -1.0. If the value overflows, the expm1 family of functions shall return HUGE_VAL and may set errno to [ERANGE]. @ page 395 line 12661 section frexp objection [tog-c99-xsh 93] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.4). Action: Add after line 12661: float frexpf(float value, int *exp); long double frexpl(long double value, int *exp); @ page 395 line 12666 section frexp objection [tog-c99-xsh 94] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.4). Action: Change "The frexp( ) function ..." To "The frexp family of functions ..." Same change on lines 12671 and 12679. @ page 395 line 12671 section frexp objection [tog-c99-xsh 95] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.4). Action: Change "The frexp( ) function shall return the value x, such that x is a double with magnitude in the ..." To "The frexp family of functions shall return the value x, such that x has a magnitude in the ..." @ page 577 line 18248 section ilogb objection [tog-c99-xsh 96] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Add after line 18248: int ilogbf(float x); int ilogbl(long double x); @ page 577 line 18251 section ilogb objection [tog-c99-xsh 97] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Change "The ilogb( ) function ..." To "The ilogb family of functions ..." @ page 577 line 18254 section ilogb objection [tog-c99-xsh 98] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Delete line 18254 (it is covered in tog-c99-xsh 99). @ page 577 line 18256-18258 section ilogb objection [tog-c99-xsh 99] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Replace lines 18256-18258 with: Upon successful completion, the ilogb family of functions shall return the exponent part of x as a signed int value. If x is zero the ilogb family of functions shall return the value FP_ILOGB0; if x is infinite they shall return the value INT_MAX; if x is a NaN they shall return the value FP_ILOGBNAN; otherwise, they shall be equivalent to calling the corresponding logb() function and casting the returned value to type int. @page 577 line 18260 section ilob objection [tog-c99-xsh 100] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.5). Action: Replace line 18260 with the following text: The ilogb family of functions may fail if: [ERANGE] The value of x is 0. @ page 656 line 20620 section ldexp objection [tog-c99-xsh 101] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.6). Action: Add after line 20620: float ldexpf(float x, int exp); long double ldexpl(long double x, int exp); @ page 656 line 20625 section ldexp objection [tog-c99-xsh 102] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.6). Action: Change "The ldexp( ) function ..." To "The ldexp family of functions ..." Same change on lines 20636 and 20638. @ page 656 line 20629-20630 section ldexp objection [tog-c99-xsh 103] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.6). Action: Change "Upon successful completion, ldexp( ) shall return a double representing the value x multiplied by 2 raised to the power exp." To "Upon successful completion, the ldexp family of functions shall return x multiplied by 2 raised to the power exp." @ page 681 line 21427 section log objection [tog-c99-xsh 104] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.7). Action: Add after line 21247: float logf(float x); long double logl(long double x); @ page 681 line 21432 section log objection [tog-c99-xsh 105] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.7). Action: Change "The log( ) function ..." To "The log family of functions ..." Same change on lines 21442 and 21444. @ page 681 line 21437 section log objection [tog-c99-xsh 106] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.7). Action: Change "Upon successful completion, log( ) ..." To "Upon successful completion, the log family of functions ..." @ page 683 line 21476 section log10 objection [tog-c99-xsh 107] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.8). Action: Add after line 21476: float log10f(float x); long double log10l(long double x); @ page 683 line 21481 section log10 objection [tog-c99-xsh 108] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.8). Action: Change "The log10( ) function ..." To "The log10 family of functions ..." Same change on lines 21491 and 21493. @ page 683 line 21486 section log10 objection [tog-c99-xsh 109] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.8). Action: Change "Upon successful completion, log10( ) ..." To "Upon successful completion, the log10 family of functions ..." @ page 685 line 21526 section log1p objection [tog-c99-xsh 110] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.9). Action: Add after line 21526: float log1pf(float x); long double log1pl(long double x); @ page 685 line 21528 section log1p objection [tog-c99-xsh 111] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.9). Action: Change "The log1p( ) function ..." To "The log1p family of functions ..." Same change on lines 21536 and 21538. @ page 685 line 21531 section log1p objection [tog-c99-xsh 112] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.9). Action: Change "Upon successful completion, log1p( ) ..." To "Upon successful completion, the log1p family of functions ..." @ page 685 line 21557 section log2 objection [tog-c99-xsh 113] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.10). Action: Add the following entry after line 21557: NAME log2 - compute base-2 logarithm SYNOPSIS #include double log2(double x); float log2f(float x); long double log2l(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The log2 family of functions shall compute the base-2 logarithm of x. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE Upon successful completion, the log2 family of functions shall return the base-2 logarithm of x. If x is NaN, the log2 family of functions shall return NaN and may set errno to [EDOM]. If x is less than 0, the log2 family of functions shall return -HUGE_VAL or NaN and set errno to [EDOM]. If x is 0, the log2 family of functions shall return -HUGE_VAL and may set errno to [ERANGE]. ERRORS The log2 family of functions shall fail if: [EDOM] The value of x is less than 0. The log2 family of functions may fail if: [EDOM] The value of x is NaN. [ERANGE] The value of x is 0. No other errors shall occur. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO log(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 686 line 21563 section logb objection [tog-c99-xsh 114] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.11). Action: Add after line 21563: float logbf(float x); long double logbl(long double x); @ page 686 line 21565 section logb objection [tog-c99-xsh 115] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.11). Action: Change "The logb( ) function ..." To "The logb family of functions ..." Same change on lines 21574 and 21576. @ page 686 line 21569 section logb objection [tog-c99-xsh 116] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.11). Action: Change "Upon successful completion, logb( ) ..." To "Upon successful completion, the logb family of functions ..." @ page 744 line 23438 section modf objection [tog-c99-xsh 117] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.12). Action: Add after line 23438: float modff(float value, float *iptr); long double modfl(long double value, long double *iptr); @ page 744 line 23443 section modf objection [tog-c99-xsh 118] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.12). Action: Change "The modf( ) function ..." To "The modf family of functions ..." Same change on line 23454. @ page 744 line 23449 section modf objection [tog-c99-xsh 119] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.12). Action: Change "Upon successful completion, modf( ) ..." To "Upon successful completion, the modf family of functions ..." @ page 1129 line 34329 section scalbn objection [tog-c99-xsh 120] Problem: Change required for alignment with C99 (ref C99 section 7.12.6.13). Action: Add the following entry after line 34329: NAME scalbn - compute exponent using FLT_RADIX SYNOPSIS #include double scalbn(double x, int n); float scalbnf(float x, int n); long double scalbnl(long double x, int n); double scalbln(double x, long int n); float scalblnf(float x, long int n); long double scalblnl(long double x, long int n); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The scalbn() and scalbln() functions shall compute x*FLT_RADIX**n efficiently, not normally by computing FLT_RADIX**n explicitly. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE Upon successful completion, the scalbn() and scalbln() functions shall return x*FLT_RADIX**n. If the correct value would overflow, the scalbn() and scalbln() functions shall return ±HUGE_VAL (according to the sign of x) and set errno to [ERANGE]. If the correct value would underflow, the scalbn() and scalbln() functions shall return 0 and set errno to [ERANGE]. The scalbn() and scalbln() functions shall return x when x is ±Inf. If x or n is NaN, then the scalbn() and scalbln() functions shall return NaN and may set errno to [EDOM]. ERRORS The scalbn() and scalbln() functions shall fail if: [ERANGE] The correct value would overflow or underflow. The scalbn() and scalbln() functions may fail if: [EDOM] The x or n argument is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE In earlier versions of the C specification, this function was called scalb. The name was changed to avoid conflicting with the Single Unix scalb function whose second argument is double instead of int. Single Unix’s scalb was not included in C9X as its specification of certain special cases is inconsistent with the C9X approach and because the scalbn and scalbln functions were considered sufficient. scalbln, whose second parameter has type long int is provided because the factor required to scale from the smallest positive floating-point value to the largest finite one, on many implementations, is too large to represent in the minimum-width int format. FUTURE DIRECTIONS None. SEE ALSO scalb(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 165 line 5267 section cbrt objection [tog-c99-xsh 121] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.1). Action: Add the following entry after line 5267: NAME cbrt - cube root functions SYNOPSIS #include double cbrt(double x); float cbrtf(float x); long double cbrtl(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The cbrt() functions shall compute the real cube root of x. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The cbrt() functions shall return x**1/3 . If x is ±Inf, the cbrt() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The cbrt() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE For some applications, a true cube root function, which returns negative results for negative arguments, is more appropriate than pow(x, 1.0/3.0), which returns a NaN for x less than 0. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 296 line 9370 section fabs objection [tog-c99-xsh 122] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.2). Action: Add after line 9370: float fabsf(float x); long double fabsl(long double x); @ page 296 line 9375 section fabs objection [tog-c99-xsh 123] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.2). Action: Change "The fabs( ) function ..." To "The fabs family of functions ..." Same change on line 9383. @ page 296 line 9379 section fabs objection [tog-c99-xsh 124] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.2). Action: Change "Upon successful completion, fabs( ) ..." To "Upon successful completion, the fabs family of functions ..." @ page 565 line 17925 section hypot objection [tog-c99-xsh 125] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.3). Action: Add after line 17925: float hypotf(float x, float y); long double hypotl(long double x, long double y); @ page 565 line 17927 section hypot objection [tog-c99-xsh 126] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.3). Action: Change "The hypot( ) function ..." To "The hypot family of functions ..." Same change on line 17939. @ page 656 line 17931 section hypot objection [tog-c99-xsh 127] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.3). Action: Change "Upon successful completion, hypot( ) ..." To "Upon successful completion, the hypot family of functions ..." @ page 880 line 27323 section pow objection [tog-c99-xsh 128] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.4). Action: Add after line 27323: float powf(float x, float y); long double powl(long double x, long double y); @ page 880 line 27328 section pow objection [tog-c99-xsh 129] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.4). Action: Change "The pow( ) function ..." To "The pow family of functions ..." Same change on lines 27344 and 27347. @ page 880 line 27333 section pow objection [tog-c99-xsh 130] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.4). Action: Change "Upon successful completion, pow( ) ..." To "Upon successful completion, the pow family of functions ..." @ page 1298 line 39389 section sqrt objection [tog-c99-xsh 131] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.5). Action: Add after line 39389: float sqrtf(float x); long double sqrtl(long double x); @ page 1298 line 39394 section sqrt objection [tog-c99-xsh 132] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.5). Action: Change "The sqrt( ) function ..." To "The sqrt family of functions ..." Same change on lines 39402 and 39404. @ page 1298 line 39398 section sqrt objection [tog-c99-xsh 133] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.5). Action: Change "Upon successful completion, sqrt( ) ..." To "Upon successful completion, the sqrt family of functions ..." @ page 1298 line 39418 section sqrt objection [tog-c99-xsh 133a] Problem: Change required for alignment with C99 (ref C99 section 7.12.7.5). Action: Change "None." To "IEC 60559, unlike the Standard, requires sqrt(-0.) to return a negatively signed magnitude-zero result. This is an issue on implementations that support a negative floating zero. The Standard specifies that taking the square root of a negative number (in the mathematical sense of less than 0) is a domain error which requires the function to return an implementation-dependent value. This rule permits implementations to support either the IEC 60559 or vendor-specific floating point representations." @ page 273 line 8555 section erf objection [tog-c99-xsh 134] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.1). Action: Add after line 8555: float erff(float x); long double erfl(long double x); @ page 273 line 8557 section erf objection [tog-c99-xsh 135] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.2). Action: Add after line 8557: float erfcf(float x); long double erfcl(long double x); @ page 273 line 8559 section erf objection [tog-c99-xsh 136] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.1). Action: Change "The erf( ) function ..." To "The erf family of functions ..." @ page 273 line 8561 section erf objection [tog-c99-xsh 137] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.2). Action: Change "The erfc( ) function ..." To "The erfc family of functions ..." @ page 273 line 8565 section erf objection [tog-c99-xsh 138] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.1). Action: Change "Upon successful completion, erf() and erfc() ..." To "Upon successful completion, the erf() and erfc() functions ..." @ page 273 line 8570 section erf objection [tog-c99-xsh 139] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.1). Action: Add after line 8570: The erfc() functions shall fail if: [ERANGE] The value of x is too large. @ page 660 line 20719 section lgamma objection [tog-c99-xsh 140] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Add after line 20719: float lgammaf(float x); long double lgammal(long double x); @ page 660 line 20713 section lgamma objection [tog-c99-xsh 141] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Change "The lgamma( ) function ..." To "The lgamma family of functions ..." Same change on lines 20719 and 20731. @ page 660 line 20724-20725 section lgamma objection [tod-c99-xsh 142] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Change "If x is a non-positive integer, either HUGE_VAL or NaN shall be returned and errno may be set to [EDOM]." To "If x is a non-positive integer, either HUGE_VAL or NaN shall be returned and errno may be set to [ERANGE]." @ page 660 line 20722 section lgamma objection [tog-c99-xsh 143] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Change "Upon successful completion, lgamma( ) ..." To "Upon successful completion, the lgamma family of functions ..." @ page 660 line 20732-20733 section lgamma objection [tog-c99-xsh 143a] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.3). Action: Change "[EDOM] The value of x is a non-positive integer or NaN. [ERANGE] The value to be returned would have caused overflow or underflow." To "[EDOM] The value of x is NaN. [ERANGE] The value of x is a non-positive integer, or the value to be returned would have caused overflow or underflow." @ page 1408 line 42746 section tgamma objection [tog-c99-xsh 144] Problem: Change required for alignment with C99 (ref C99 section 7.12.8.4). Action: Add the following entry after line 42746: NAME tgamma - compute gamma function SYNOPSIS #include double tgamma(double x); float tgammaf(float x); long double tgammal(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The tgamma() functions shall compute the gamma function of x. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The tgamma() functions shall return Gamma(x). If x is NaN, NaN shall be returned and errno may be set to [EDOM]. If x is a negative integer, or if the result cannot be represented when x is 0, either HUGE_VAL or NaN shall be returned and errno shall be set to [EDOM]. If the magnitude of x is too large or too small, ±HUGE_VAL shall be returned and errno shall be set too [ERANGE] ERRORS The tgamma() functions shall fail if: [EDOM] The value of x is negative or the result cannot be represented when x is zero. [ERANGE] The magnitude of x is too large or too small. The tgamma() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE In many other standards, the meaning of gamma has changed over the years. Originally, it computed the logarithm of the absolute value of the mathematical gamma function, with an external int, signgam, being set to the sign of the gamma function. Then gamma was replaced with lgamma, and gamma was slated to be withdrawn. About that time, NCEG changed gamma to compute the mathematical gamma function, and that is what was adopted into C9X CD1; but it appears that the old meaning of gamma has not yet been withdrawn, so there would have been a conflict between C9X and current industry practice. C9X therefore changed the name in the FCD to tgamma, meaning “true gamma,” to avoid this conflict. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 172 line 5460 section ceil objection [tog-c99-xsh 145] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.1). Action: Add after line 5460: float ceilf(float x); long double ceill(long double x); @ page 172 line 5465 section ceil objection [tog-c99-xsh 146] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.1). Action: Change "The ceil( ) function ..." To "The ceil family of functions ..." Same change on lines 5475 and 5477. @ page 172 line 5469 section ceil objection [tog-c99-xsh 147] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.1). Action: Change "Upon successful completion, ceil( ) ..." To "Upon successful completion, the ceil family of functions ..." @ page 342 line 10791 section floor objection [tog-c99-xsh 148] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.2). Action: Add after line 10791: float floorf(float x); long double floorl(long double x); @ page 342 line 1076 section floor objection [tog-c99-xsh 149] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.2). Action: Change "The floor( ) function ..." To "The floor family of functions ..." Same change on lines 10807 and 10809. @ page 342 line 10800 section floor objection [tog-c99-xsh 150] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.2). Action: Change "Upon successful completion, floor( ) ..." To "Upon successful completion, the floor family of functions ..." @ page 786 line 24685 section nearbyint objection [tog-c99-xsh 151] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.3). Action: Add the following entry after line 24685: NAME nearbyint - floating-point rounding functions SYNOPSIS #include double nearbyint(double x); float nearbyintf(float x); long double nearbyintl(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The nearbyint() functions shall round their argument to an integer value in floating-point format, using the current rounding direction and without raising the ‘‘inexact’’ floating-point exception. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The nearbyint() functions shall return the rounded integer value. If x is ±Inf, the nearbyint() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The nearbyint() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 1124 line 34131 section rint objection [tog-c99-xsh 152] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.4). Action: Add after line 34131: float rintf(float x); long double rintl(long double x); @ page 1124 line 34134 section rint objection [tog-c99-xsh 153] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.4). Action: Remove XSI annotation from entry and add the following text after line 34134: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. @ page 1124 line 34134 section rint objection [tog-c99-xsh 154] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.4). Action: Change "The rint( ) function ..." To "The rint family of functions ..." Same change on line 34145. @ page 1124 line 34138 section rint objection [tog-c99-xsh 155] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.4). Action: Add the folowing text after line 34138: The rint() functions differ from the nearbyint() functions only in that the rint() functions may raise the ‘‘inexact’’ floating-point exception if the result differs in value from the argument. @ page 1124 line 34140 section rint objection [tog-c99-xsh 156] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.2). Action: Change "Upon successful completion, rint( ) ..." To "Upon successful completion, the rint family of functions ..." @ page 689 line 21662 section lrint objection [tog-c99-xsh 157] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.5). Action: Add the following entry after line 21662: NAME lrint - round to nearest integer value using current rounding direction SYNOPSIS #include long int lrint(double x); long int lrintf(float x); long int lrintl(long double x); long long int llrint(double x); long long int llrintf(float x); long long int llrintl(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The lrint() and llrint() functions shall round their argument to the nearest integer value, rounding according to the current rounding direction. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, an error has occurred. RETURN VALUE The lrint() and llrint() functions shall return the rounded integer value. If the rounded value is outside the range of the return type, the numeric result is unspecified. If the magnitude of x is too large, the numeric result is unspecified and errno may be set to [ERANGE]. ERRORS The lrint() and llrint() functions may fail if: [ERANGE] The magnitude of x is too large. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 1128 line 34290 section round objection [tog-c99-xsh 158] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.6). Action: Add the following entry after line 34290: NAME round - round to nearest integer value in floating-point format SYNOPSIS #include double round(double x); float roundf(float x); long double roundl(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The round() functions shall round their argument to the nearest integer value in floating-point format, rounding halfway cases away from zero, regardless of the current rounding direction. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The round() functions shall return the rounded integer value. If x is ±Inf, the round() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The round() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 689 line 21662 section lround objection [tog-c99-xsh 159] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.7). Action: Add the following entry after line 21662: NAME lround - round to nearest integer value SYNOPSIS #include long int lround(double x); long int lroundf(float x); long int lroundl(long double x); long long int llround(double x); long long int llroundf(float x); long long int llroundl(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The lround() and llround() functions shall round their argument to the nearest integer value, rounding halfway cases away from zero, regardless of the current rounding direction. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, an error has occurred. RETURN VALUE The lround() and llround() functions shall return the rounded integer value. If the rounded value is outside the range of the return type, the numeric result is unspecified. If the magnitude of x is too large, the numeric result is unspecified and errno may be set to [ERANGE]. ERRORS The lround() and llround() functions may fail if: [ERANGE] The magnitude of x is too large. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 1432 line 43530 section trunc objection [tog-c99-xsh 160] Problem: Change required for alignment with C99 (ref C99 section 7.12.9.8). Action: Add the following entry after line 34290: NAME trunc - round to truncated integer value SYNOPSIS #include double trunc(double x); float truncf(float x); long double truncl(long double x); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The trunc() functions shall round their argument to the integer value, in floating format, nearest to but no larger in magnitude than the argument. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The trunc() functions shall return the truncated integer value. If x is ±Inf, the trunc() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The round() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 344 line 10842 section fmod objection [tog-c99-xsh 161] Problem: Change required for alignment with C99 (ref C99 section 7.12.10.1). Action: Add after line 10842: float fmodf(float x, float y); long double fmodl(long double x, long double y); @ page 344 line 10847 section fmod objection [tog-c99-xsh 162] Problem: Change required for alignment with C99 (ref C99 section 7.12.10.1). Action: Change "The fmod( ) function ..." To "The fmod family of functions ..." Same change on lines 10852 and 10862. @ page 1111 line 33760 section remainder objection [tog-c99-xsh 163] Problem: Change required for alignment with C99 (ref C99 section 7.12.10.2). Action: Add after line 1111: float remainderf(float x, float y); long double remainderl(long double x, long double y); @ page 1111 line 33763 section remainder objection [tog-c99-xsh 164] Problem: Change required for alignment with C99 (ref C99 section 7.12.10.2). Action: Change "The remainder( ) function ..." To "The remainder family of functions ..." Same change on lines 33768, 33773 and 33775. @ page 1114 line 33847 section remquo objection [tog-c99-xsh 165] Problem: Change required for alignment with C99 (ref C99 section 7.12.10.3). Action: Add the following entry after line 33847: NAME remquo - remainder functions SYNOPSIS #include double remquo(double x, double y, int *quo); float remquof(float x, float y, int *quo); long double remquol(long double x, long double y, int *quo); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The remquo() functions shall compute the same remainder as the remainder() functions. In the object pointed to by quo they store a value whose sign is the sign of x/y and whose magnitude is congruent modulo 2**n to the magnitude of the integral quotient of x/y, where n is an implementation-dependent integer greater than or equal to 3. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The remquo() functions shall return x REM y. When y is 0, the remquo() functions shall return NaN (or equivalent if available) and set errno to [EDOM]. If the value of x is ±Inf, the remquo() functions shall return NaN and set errno to [EDOM]. If x or y is NaN, then the functions shall return NaN and errno may be set to [EDOM]. ERRORS The remquo() functions shall fail if: [EDOM] The y argument is 0 or the x argument is positive or negative infinity. The remquo() functions may fail if: [EDOM] The x or y argument is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE The remquo functions are intended for implementing argument reductions which can exploit a few low-order bits of the quotient. Note that x may be so large in magnitude relative to y that an exact representation of the quotient is not practical. FUTURE DIRECTIONS None. SEE ALSO remainder(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 216 line 6910 section copysign objection [tog-c99-xsh 166] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.1). Action: Add the following entry after line 6910: NAME copysign - number manipulation function SYNOPSIS #include double copysign(double x, double y); float copysignf(float x, float y); long double copysignl(long double x, long double y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The copysign() functions shall produce a value with the magnitude of x and the sign of y. They produce a NaN (with the sign of y) if x is a NaN. On implementations that represent a signed zero but do not treat negative zero consistently in arithmetic operations, the copysign functions regard the sign of zero as positive. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The copysign() functions shall return a value with the magnitude of x and the sign of y. If x is ±Inf, the copysign() functions shall return x. If x is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The copysign() functions may fail if: [EDOM] The value of x is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE copysign and signbit need not be consistent with each other if the arithmetic is not consistent in its treatment of zeros. For example, the IBM S/370 has instructions to flip the sign bit making it possible to create a negative zero, but ±0.0 × ±1.0 is always +0.0. In this case, copysign will treat –0.0 as positive, while signbit will treat it as negative. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 784 line 24628 section nan objection [tog-c99-xsh 167] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.2). Action: Add the following entry after line 24628: NAME nan - return quiet NaN SYNOPSIS #include double nan(const char *tagp); float nanf(const char *tagp); long double nanl(const char *tagp); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The call nan("n-char-sequence") shall be equivalent to strtod("NAN(n-char-sequence)", (char**) NULL); the call nan("") shall be equivalent to strtod("NAN()", (char**) NULL). If tagp does not point to an n-char sequence or an empty string, the call shall be equivalent to strtod("NAN", (char**) NULL). Calls to nanf() and nanl() are equivalent to the corresponding calls to strtof() and strtold(). RETURN VALUE The nan() functions shall return a quiet NaN, if available, with content indicated through tagp. If the implementation does not support quiet NaNs, the functions shall return zero. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO strtod(), strtof(), strtold(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 787 line 24690 section nextafter objection [tog-c99-xsh 168] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Add after line 24690: float nextafterf(float x, float y); long double nextafterl(long double x, long double y); double nexttoward(double x, long double y); float nexttowardf(float x, long double y); long double nexttowardl(long double x, long double y); @ page 787 line 24692 section nextafter objection [tog-c99-xsh 169] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Add the following text after line 24692: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. @ page 787 line 24693 section nextafter objection [tog-c99-xsh 170] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Change "The nextafter( ) function ..." To "The nextafter family of functions ..." @ page 787 line 24695 section nextafter objection [tog-c99-xsh 171] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Change "representable floating-point number less than x." To "representable floating-point number less than x. The nextafter() functions shall return y is x equals y." @ page 787 line 24695 section nextafter objection [tog-c99-xsh 172] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Add the following text after line 24695: The nexttoward() functions are equivalent to the nextafter() functions except that the second parameter has type long double and the functions return y converted to the type of the function if x equals y. @ page 787 line 24699 section nextafter objection [tog-c99-xsh 173] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Change "The nextafter() function ..." To "The nextafter() and nexttoward() functions ..." The same change applies to lines 24705 and 24707. @ page 787 line 24700 section nextafter objection [tog-c99-xsh 174] Problem: Change required for alignment with C99 (ref C99 section 7.12.11.3). Action: Add the following text after line 24700: The nextafter() functions shall return y if x equals y. @ page 318 line 10114 section fdim objection [tog-c99-xsh 175] Problem: Change required for alignment with C99 (ref C99 section 7.12.12.1). Action: Add the following entry after line 10114: NAME fdim - compute positive difference between two floating-point numbers SYNOPSIS #include double fdim(double x, double y); float fdimf(float x, float y); long double fdiml(long double x, long double y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fdim functions shall determine the positive difference between their arguments. If x is greater than y, x - y is returned. If x is less than or equal to y, +0 is returned. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The fdim() functions shall return the positive difference value. If x or y is NaN, NaN shall be returned and errno may be set to [EDOM]. If the magnitude of the result is too large or too small, the numeric result is unspecified and errno may be set to [ERANGE]. ERRORS The fdim() functions may fail if: [EDOM] The value of x or y is NaN. [ERANGE] The magnitude of the result is too large or too small. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fmax(), fmin(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 343 line 10837 section fmax objection [tog-c99-xsh 176] Problem: Change required for alignment with C99 (ref C99 section 7.12.12.2). Action: Add the following entry after line 10837: NAME fmax - determine maximum numeric value of two floating-point numbers SYNOPSIS #include double fmax(double x, double y); float fmaxf(float x, float y); long double fmaxl(long double x, long double y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fmax() functions shall determine the maximum numeric value of their arguments. NaN arguments shall be treated as missing data: if one argument is a NaN and the other numeric, then the fmax() functions shall choose the numeric value. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The fmax() functions shall return the maximum numeric value of their arguments. If x and y are NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The fmax() functions may fail if: [EDOM] The value of x and y is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fdim(), fmin(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 343 line 10837 section fmin objection [tog-c99-xsh 177] Problem: Change required for alignment with C99 (ref C99 section 7.12.12.3). Action: Add the following entry after line 10837: NAME fmin - determine minimum numeric value of two floating-point numbers SYNOPSIS #include double fmin(double x, double y); float fminf(float x, float y); long double fminl(long double x, long double y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fmin() functions shall determine the minimum numeric value of their arguments. NaN arguments shall be treated as missing data: if one argument is a NaN and the other numeric, then the fmin() functions shall choose the numeric value. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The fmin() functions shall return the minimum numeric value of their arguments. If x and y are NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The fmin() functions may fail if: [EDOM] The value of x and y is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fdim(), fmax(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 343 line 10837 section fma objection [tog-c99-xsh 178] Problem: Change required for alignment with C99 (ref C99 section 7.12.13.1). Action: Add the following entry after line 10837: NAME fma - floating-point multiply-add SYNOPSIS #include double fma(double x, double y, double z); float fmaf(float x, float y, float z); long double fmal(long double x, long double y, long double z); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The fma() functions shall compute (x * y) + z, rounded as one ternary operation: they shall compute the value (as if) to infinite precision and round once to the result format, according to the rounding mode characterized by the value of FLT_ROUNDS. An application wishing to check for error situations should set errno to 0 before calling these functions. If errno is non-zero on return, or the return value is NaN, an error has occurred. RETURN VALUE The fma() functions shall return (x * y) + z, rounded as one ternary operation. If x, y or z is NaN, NaN shall be returned and errno may be set to [EDOM]. ERRORS The fma() functions may fail if: [EDOM] The value of x, y or z is NaN. EXAMPLES None. APPLICATION USAGE None. RATIONALE In many cases, clever use of floating (fused) multiply-add leads to much improved code; but its unexpected use by the compiler can undermine carefully written code. The FP_CONTRACT macro can be used to disallow use of floating multiply-add; and the fma function guarantees its use where desired. Many current machines provide hardware floating multiply-add instructions; software implementation can be used for others. FUTURE DIRECTIONS None. SEE ALSO The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 613 line 19466 section isgreater objection [tog-c99-xsh 179] Problem: Change required for alignment with C99 (ref C99 section 7.12.14.1). Action: Add the following entry after line 19466: NAME isgreater - test if x greater than y SYNOPSIS #include int isgreater(real-floating x, real-floating y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isgreater() macro shall determine whether its first argument is greater than its second argument. The value of isgreater(x, y) shall be equal to (x) > (y); however, unlike (x) > (y), isgreater(x, y) shall not raise the ‘‘invalid’’ floating-point exception when x and y are unordered. RETURN VALUE The isgreater() macro shall return the value of (x) > (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships — less, greater, and equal — is true. Relational operators may raise the ‘‘invalid’’ floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the ‘‘invalid’’ floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the ‘‘invalid’’ floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreaterequal(), isless(), islessequal(), islessgreater(), isunordered(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 613 line 19466 section isgreaterequal objection [tog-c99-xsh 180] Problem: Change required for alignment with C99 (ref C99 section 7.12.14.2). Action: Add the following entry after line 19466: NAME isgreaterequal - test if x greater than or equal to y SYNOPSIS #include int isgreaterequal(real-floating x, real-floating y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isgreaterequal() macro shall determine whether its first argument is greater than or equal to its second argument. The value of isgreaterequal(x, y) shall be equal to (x) >= (y); however, unlike (x) >= (y), isgreaterequal(x, y) shall not raise the ‘‘invalid’’ floating-point exception when x and y are unordered. RETURN VALUE The isgreaterequal() macro shall return the value of (x) >= (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships — less, greater, and equal — is true. Relational operators may raise the ‘‘invalid’’ floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the ‘‘invalid’’ floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the ‘‘invalid’’ floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isless(), islessequal(), islessgreater(), isunordered(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 613 line 19466 section isless objection [tog-c99-xsh 181] Problem: Change required for alignment with C99 (ref C99 section 7.12.14.3). Action: Add the following entry after line 19466: NAME isless - test if x less than y SYNOPSIS #include int isless(real-floating x, real-floating y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isless() macro shall determine whether its first argument is less than its second argument. The value of isless(x, y) shall be equal to (x) < (y); however, unlike (x) < (y), isless(x, y) shall not raise the ‘‘invalid’’ floating-point exception when x and y are unordered. RETURN VALUE The isless() macro shall return the value of (x) < (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships — less, greater, and equal — is true. Relational operators may raise the ‘‘invalid’’ floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the ‘‘invalid’’ floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the ‘‘invalid’’ floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isgreaterequal(), islessequal(), islessgreater(), isunordered(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 613 line 19466 section islessequal objection [tog-c99-xsh 182] Problem: Change required for alignment with C99 (ref C99 section 7.12.14.4). Action: Add the following entry after line 19466: NAME islessequal - test if x less than or equal to y SYNOPSIS #include int islessequal(real-floating x, real-floating y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The islessequal() macro shall determine whether its first argument is less than or equal to its second argument. The value of islessequal(x, y) shall be equal to (x) <= (y); however, unlike (x) <= (y), islessequal(x, y) shall not raise the ‘‘invalid’’ floating-point exception when x and y are unordered. RETURN VALUE The islessequal() macro shall return the value of (x) <= (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships — less, greater, and equal — is true. Relational operators may raise the ‘‘invalid’’ floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the ‘‘invalid’’ floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the ‘‘invalid’’ floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isgreaterequal(), isless(), islessgreater(), isunordered(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 613 line 19466 section islessgreater objection [tog-c99-xsh 183] Problem: Change required for alignment with C99 (ref C99 section 7.12.14.5). Action: Add the following entry after line 19466: NAME islessgreater - test if x less than or greater than y SYNOPSIS #include int islessgreater(real-floating x, real-floating y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The islessgreater() macro shall determine whether its first argument is less than or greater than its second argument. The islessgreater(x, y) macro is similar to (x) < (y) || (x) > (y); however, islessgreater(x, y) shall not raise the ‘‘invalid’’ floating-point exception when x and y are unordered (nor shall it evaluate x and y twice). RETURN VALUE The islessgreater() macro shall return the value of (x) < (y) || (x) > (y). If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships — less, greater, and equal — is true. Relational operators may raise the ‘‘invalid’’ floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the ‘‘invalid’’ floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the ‘‘invalid’’ floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isgreaterequal(), isless(), islessequal(), isunordered(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 619 line 19678 section isunordered objection [tog-c99-xsh 184] Problem: Change required for alignment with C99 (ref C99 section 7.12.14.6). Action: Add the following entry after line 19678: NAME isunordered - test if arguments are unordered SYNOPSIS #include int isunordered(real-floating x, real-floating y); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C standard. The isunordered() macro shall determine whether its arguments are unordered. RETURN VALUE The isunordered() macro shall return 1 if its arguments are unordered and 0 otherwise. If x or y is NaN, 0 shall be returned. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE The relational and equality operators support the usual mathematical relationships between numeric values. For any ordered pair of numeric values exactly one of the relationships — less, greater, and equal — is true. Relational operators may raise the ‘‘invalid’’ floating-point exception when argument values are NaNs. For a NaN and a numeric value, or for two NaNs, just the unordered relationship is true. This macro is a quiet (non floating-point exception raising) version of a relational operator. It facilitates writing efficient code that accounts for NaNs without suffering the ‘‘invalid’’ floating-point exception. In the SYNOPSIS section, real-floating indicates that the argument shall be an expression of real floating type. IEC 60559 requires that the built-in relational operators raise the ‘‘invalid’’ floating-point exception if the operands compare unordered, as an error indicator for programs written without consideration of NaNs; the result in these cases is false. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO isgreater(), isgreaterequal(), isless(), islessequal(), islessgreater(), The System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY Issue 6 Entry included for alignment with C99. @ page 1194 line 36394 section setjmp objection [tog-c99-xsh 185] Problem: Change required for alignment with C99 (ref C99 section 7.13.1.1). Action: Add the following statement after line 36394: "If the Invocation appears in any other context, the behaviour is undefined." @ page 687 line 21602-21604 section longjmp objection [tog-c99-xsh 186] Problem: Change required for alignment with C99 (ref C99 section 7.13.2.1). Action: Change "If there is no such invocation, or if the function containing the invocation of setjmp() has terminated execution in the interim, the behavior is undefined." To "If there is no such invocation, or if the function containing the invocation of setjmp()macro has terminated execution in the interim, or if the invocation of setjmp() was within the scope of an identifier with variably modified type and execution has left that scope in the interim, the behavior is undefined." @ page 687 line 21607 section longjmp objection [tog-c99-xsh 187] Problem: Change required for alignment with C99 (ref C99 section 7.13.2.1). Action: Change "All accessible objects have values as of the time setjmp( ) was called, except that the values of ..." Change "All accessible objects have values as of the time setjmp( ) was called, and all other components of the abstract machine have state (for example, floating-point status flags and open files), except that the values of ..." @ page 1265 line 38464-38465 section signal objection [tog-c99-xsh 188] Problem: Change required for alignment with C99 (ref C99 section 7.14.1.1). Action: Change "Such a function is called a signal handler." To "An invocation of such a function because of a signal, or (recursively) of any further functions called by that invocation (other than functions in the standard library), is called a signal handler." @ page 1265 line 38476 section signal objection [tog-c99-xsh 189] Problem: Change required for alignment with C99 (ref C99 section 7.14.1.1). Action: Add the following text after line 38476: "If the signal occurs as the result of calling the abort() or raise() function, the signal handler shall not call the raise function." @ page 1265 line 38477-38478 section signal objection [tog-c99-xsh 190] Problem: Change required for alignment with C99 (ref C99 section 7.14.1.1). Action: Change "If the signal occurs other than as the result of calling abort(), kill (), or raise( ), the behavior is undefined if the signal handler calls any function in the standard library ..." To "If the signal occurs other than as the result of calling abort(), kill (), or raise( ), the behavior is undefined if the signal handler rrefers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t, or if the signal handler calls any function in the standard library ..." @ page 1069 line 32348 section raise objection [tog-c99-xsh 191] Problem: Change required for alignment with C99 (ref C99 section 7.14.2.1). Action: Change "The raise( ) function shall send the signal sig to the executing thread." To "The raise( ) function shall send the signal sig to the executing thread. If a signal handler is called, the raise() function shall not return until after the signal handler does." @ page 1471 line 44674 section va_arg objection [tog-c99-xsh 192] Problem: Change required for alignment with C99 (ref C99 section 7.15). Action: Change "va_arg, va_end, va_start — handle variable argument list" To "va_arg, va_copy, va_end, va_start — handle variable argument list" @ page 1471 line 44677 section va_arg objection [tog-c99-xsh 193] Problem: Change required for alignment with C99 (ref C99 section 7.15). Action: Add the following after line 44677: void va_copy(va_list dest, va_list src); @ page 1424 line 43221 section tmpfile objection [tog-c99-xsh 194] Problem: Change required for alignment with C99 (ref C99 section 7.19.4.3). Action: Change "None." To "It should be possible to open at least TMP_MAX temporary files during the lifetime of the program (this limit may be shared with tmpnam) and there should be no limit on the number simultaneously open other than this limit and any limit on the number of open files (FOPEN_MAX)." @ page 1425 line 43259-43260 section tmpnam objection [tog-c99-xsh 195] Problem: Change required for alignment with C99 (ref C99 section 7.19.4.4). Action: Change "The tmpnam( ) function shall generate a string that is a valid file name and that is not the same as the name of an existing file." To "The tmpnam( ) function shall generate a string that is a valid file name and that is not the same as the name of an existing file. The function is potentially capable of generating TMP_MAX different strings, but any or all of them may already be in use by existing files and thus not be suitable return values." @ page 1425 line 43270 section tmpnam objection [tog-c99-xsh 196] Problem: Change required for alignment with C99 (ref C99 section 7.19.4.6). Action: Add the following text after line 43270: If no suitable string can be generated, the tmpnam function shall return a null pointer. @ page 306 line 9663 section fclose objection [tog-c99-xsh 197] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.1). Action: Change "The stream shall be disassociated from the file." To "Whether or not the call succeeds, the stream shall be disassociated from the file and any buffer set by the setbuf() or setvbuf() function shall be disassociated from the stream" @ page 324 line 10277 section fflush objection [tog-c99-xsh 198] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.2). Action: Change " ... otherwise, it shall return EOF and set errno ..." Change " ... otherwise, it shall set the error indictator for the stream, return EOF and set errno ..." @ page 351 line 11064 section fopen objection [tog-c99-xsh 199] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.3). Action: Change "FILE *fopen(const char * filename, const char * mode);" To "FILE *fopen(const char * restrict filename, const char * restrict mode);" @ page 351 line 11071 section fopen objection [tog-c99-xsh 200] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.3). Action: Change "The argument mode points to a string beginning with one of the following sequences:" To "The argument mode points to a string. If the string is one of the following, the file is open in the indicated mode. Otherwise, the behavior is undefined." @ page 392 line 12541 section freopen objection [tog-c99-xsh 201] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.4). Action: Change "FILE *freopen(const char * filename, const char * mode, FILE * stream);" To "FILE *freopen(const char * restrict filename, const char * restrict mode, FILE * restrict stream);" @ page 392 line 12551 section freopen objection [tog-c99-xsh 202] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.4). Action: Add the following text after line 12551: If filename is a null pointer, the freopen() function shall attempt to change the mode of the stream to that specified by mode, as if the name of the file currently associated with the stream had been used. It is implementation-dependent which changes of mode are permitted (if any), and under what circumstances. @ page 1183 line 36129 section setbuf objection [tog-c99-xsh 203] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.5). Action: Change "void setbuf(FILE * stream, char * buf);" To "void setbuf(FILE * restrict stream, char * restrict buf);" @ page 1227 line 37214 section setvbuf objection [tog-c99-xsh 204] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.6). Action: Change "int setvbuf(FILE * stream, char * buf, int type, size_t size);" To "int setvbuf(FILE * restrict stream, char * restrict buf, int type, size_t size);" @ page 1227 line 37220 section setvbuf objection [tog-c99-xsh 205] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.6). Action: Change "... but before any other operation is performed on the stream." To "... but before any other operation (other than an unsuccessful call to setvbuf()) is performed on the stream." @ page 1227 line 37225-37226 section setvbuf objection [tog-c99-xsh 206] Problem: Change required for alignment with C99 (ref C99 section 7.19.5.6). Action: Change "If buf is not a null pointer, the array it points to may be used instead of a buffer allocated by setvbuf( ). The argument size specifies the size of the array. ..." To "If buf is not a null pointer, the array it points to may be used instead of a buffer allocated by setvbuf( ) and the argument size specifies the size of the array; otherwise, size may determine the size of a buffer allocated by the setvbuf function. ..." @ page 365 line 11593-11596 section fprintf objection [tog-c99-xsh 207] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "int fprintf(FILE * stream, const char * format, ...); int printf(const char * format, ...); int snprintf(char *s, size_t n, const char * format, ...); int sprintf(char *s, const char * format, ...);" To "int fprintf(FILE * restrict stream, const char * restrict format, ...); int printf(const char * restrict format, ...); int snprintf(char * restrict s, size_t n, const char * restrict format, ...); int sprintf(char * restrict s, const char * restrict format, ...);" And remove XSI shading from snprint(). @ page 366 line 11646-11657 section fprintf objection [tog-c99-xsh 208] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change lines 11646-11657 to contain only the following text: "* An optional length modifier that specifies the size of the argument." @ page 367 line 11700 section fprintf objection [tog-c99-xsh 209] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Add the following text after line 11700: The length modifiers and their meanings are: hh Specifies that a following d, i, o, u, x,orXconversion specifier applies to a signed char or unsigned char argument (the argument will have been promoted according to the integer promotions, but its value shall be converted to signed char or unsigned char before printing); or that a following n conversion specifier applies to a pointer to a signed char argument. h Specifies that a following d, i, o, u, x,orXconversion specifier applies to a short int or unsigned short int argument (the argument will have been promoted according to the integer promotions, but its value shall be converted to short int or unsigned short int before printing); or that a following n conversion specifier applies to a pointer to a short int argument. l (ell) Specifies that a following d, i, o, u, x,orXconversion specifier applies to a long int or unsigned long int argument; that a following n conversion specifier applies to a pointer to a long int argument; that a following c conversion specifier applies to a wint_t argument; that a following s conversion specifier applies to a pointer to a wchar_t argument; or has no effect on a following a, A, e, E, f, F, g,orGconversion specifier. ll (ell-ell) Specifies that a following d, i, o, u, x,orXconversion specifier applies to a long long int or unsigned long long int argument; or that a following n conversion specifier applies to a pointer to a long long int argument. j Specifies that a following d, i, o, u, x,orXconversion specifier applies to an intmax_t or uintmax_t argument; or that a following n conversion specifier applies to a pointer to an intmax_t argument. z Specifies that a following d, i, o, u, x,orXconversion specifier applies to a size_t or the corresponding signed integer type argument; or that a following n conversion specifier applies to a pointer to a signed integer type corresponding to size_t argument. t Specifies that a following d, i, o, u, x,orXconversion specifier applies to a ptrdiff_t or the corresponding unsigned integer type argument; or that a following n conversion specifier applies to a pointer to a ptrdiff_t argument. L Specifies that a following a, A, e, E, f, F, g,orGconversion specifier applies to a long double argument. If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. @ page 367 line 11723 section fprintf objection [tog-c99-xsh 210] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "f A double argument ..." To "f,F A double argument ..." @ page 368 line 11728-11729 section fprintf objection [tog-c99-xsh 211] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "The fprintf ( ) family of functions may make available character string representations for infinity and NaN." To "A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity - which style is implementation-dependent. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-dependent. The F conversion specifier produces INF, INFINITY,orNAN instead of inf, infinity,ornan, respectively." And remove the XSI margin mark. @ page 368 line 11737-11738 section fprintf objection [tog-c99-xsh 212] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "The fprintf ( ) family of functions may make available character string representations for infinity and NaN." To " A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier." And remove the XSI margin mark. @ page 368 line 11746-11747 section fprintf objection [tog-c99-xsh 213] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "The fprintf ( ) family of functions may make available character string representations for infinity and NaN." To " A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier." And remove the XSI margin mark. @ page 368 line 11748 section fprintf objection [tog-c99-xsh 214] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Add the folowing text after line 11748: a,A A double argument representing a floating-point number is converted in the style [-]0xh.hhhh p±d, where there is one hexadecimal digit (which is nonzero if the argument is a normalized floating-point number and is otherwise unspecified) before the decimal-point character 235) and the number of hexadecimal digits after it is equal to the precision; if the precision is missing and FLT_RADIX is a power of 2, then the precision is sufficient for an exact representation of the value; if the precision is missing and FLT_RADIX is not a power of 2, then the precision is sufficient to distinguish 236) values of type double, except that trailing zeros may be omitted; if the precision is zero and the # flag is not specified, no decimal-point character appears. The letters abcdef are used for a conversion and the letters ABCDEF for A conversion. The A conversion specifier produces a number with X and P instead of x and p. The exponent always contains at least one digit, and only as many more digits as necessary to represent the decimal exponent of 2. If the value is zero, the exponent is zero. A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier. @ page 369 line 11779 section fprintf objection [tog-c99-xsh 215] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Change "If a conversion specification does not match one of the above forms, the behavior is undefined." To "If a conversion specification does not match one of the above forms, the behavior is undefined. If any argument is not the correct type for the corresponding conversion specification, the behavior is undefined." @ page 369 line 11783 section fprintf objection [tog-c99-xsh 216] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.1). Action: Add the following text after line 11783: For a and A conversions, if FLT_RADIX is a power of 2, the value is correctly rounded to a hexadecimal floating number with the given precision. If FLT_RADIX is not a power of 2, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction. For e, E, f, F, g, and G conversions, if the number of significant decimal digits is at most DECIMAL_DIG, then the result should be correctly rounded. If the number of significant decimal digits is more than DECIMAL_DIG but the source value is exactly representable with DECIMAL_DIG digits, then the result should be an exact representation with trailing zeros. Otherwise, the source value is bounded by two adjacent decimal strings L < U, both having DECIMAL_DIG significant digits; the value of the resultant decimal string D should satisfy L <= D <= U, with the extra stipulation that the error should have a correct sign for the current rounding direction. @ page 98 line 12709-12711 section fscanf objection [tog-c99-xsh 217] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Change "int fscanf(FILE * stream, const char * format, ... ); int scanf(const char * format, ... ); int sscanf(const char * s, const char * format, ... );" To: "int fscanf(FILE * restrict stream, const char * restrict format, ... ); int scanf(const char * restrict format, ... ); int sscanf(const char * restrict s, const char * restrict format, ... );" @ page 398-399 line 12745-12755 section fscanf objection [tog-c99-xsh 218] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Change lines 12745-12755 to contain only the following text: "* An optional length modifier that specifies the size of the receiving object." @ page 399 line 12789 section fscanf objection [tog-c99-xsh 219] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Add the following text after line 12789: The length modifiers and their meanings are: hh Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to signed char or unsigned char. h Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to short int or unsigned short int. l (ell) Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to long int or unsigned long int; that a following a, A, e, E, f, F, g,or G conversion specifier applies to an argument with type pointer to double; or that a following c, s,or[ conversion specifier applies to an argument with type pointer to wchar_t. ll (ell-ell) Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to long long int or unsigned long long int. j Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to intmax_t or uintmax_t. z Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to size_t or the corresponding signed integer type. t Specifies that a following d, i, o, u, x, X,or n conversion specifier applies to an argument with type pointer to ptrdiff_t or the corresponding unsigned integer type. L Specifies that a following a, A, e, E, f, F, g,or G conversion specifier applies to an argument with type pointer to long double. If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. @ page 399 line 12767 section fscanf objection [tog-c99-xsh 220] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Add the following text to the end of line 12767: Similarly, if end-of-file, an encoding error, or a read error prevents a character from being read, the directive fails. @ page 400 line 12811 section fscanf objection [tog-c99-xsh 221] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Change "e,f g Matches an optionally signed floating-point number, whose format is the same as ..." To "a,e,f g Matches an optionally signed floating-point number, infinity or NaN, whose format is the same as ..." @ page 401 line 12875 section fscanf objection [tog-c99-xsh 222] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Add the following text to the end of line 12875: No argument is converted, but one is consumed. If the conversion specification includes an assignment-suppressing character or a field width, the behavior is undefined. @ page 401 line 12881 section fscanf objection [tog-c99-xsh 223] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.2). Action: Change "The conversion characters E, G, and X are also valid and behave the same as, respectively, e, g, and x." To "The conversion characters A, E, F, G and X are also valid and behave the same as, respectively, a, e, f, g, and x." @ page 883 line 27386 section printf objection [tog-c99-xsh 224] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.3). Action: Change "int printf(const char * format, ...);" To "int printf(const char * restrict format, ...);" @ page 1130 line 34334 section scanf objection [tog-c99-xsh 225] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.4). Action: Change "int scanf(const char * format, ... );" To "int scanf(const char * restrict format, ... );" @ page 1297 line 39381-39382 section sprintf objection [tog-c99-xsh 226] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.5-6). Action: Change "int snprintf(char *s, size_t n, const char * format, ...); int sprintf(char * s, const char * format, ...);" To "int snprintf(char * restrict s, size_t n, const char * restrict format, ...); int sprintf(char * restrict s, const char * restrict format, ...);" And remove XSI shading on snprintf(). @ page 1303 line 39461 section sscanf objection [tog-c99-xsh 227] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.7). Action: Change "int sscanf(const char * s, const char * format, ...);" To "int sscanf(const char * restrict s, const char * restrict format, ...);" @ page 1474 line 44741-44744 section vfprintf objection [tog-c99-xsh 228] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.8). Action: Change "int vfprintf(FILE * stream, const char * format, va_list ap); int vprintf(const char * format, va_list ap); int vsnprintf(char * s, size_t n, const char * format, va_list ap); int vsprintf(char * s, const char * format, va_list ap);" To "int vfprintf(FILE * restrict stream, const char * restrict format, va_list ap); int vprintf(const char * restrict format, va_list ap); int vsnprintf(char * restrict s, size_t n, const char * restrict format, va_list ap); int vsprintf(char * restrict s, const char * restrict format, va_list ap);" @ page 1475 line 44783 section vfscanf objection [tog-c99-xsh 229] Problem: Change required for alignment with C99 (ref C99 section 7.19.6.9). Action: Add the following entry after line 44783 NAME vfscanf - format input of a stdarg list SYNOPSIS #include #include int vfscanf(FILE * restrict stream, const char * restrict format, va_list arg); int vscanf(const char * restrict format, va_list arg); int vsscanf(const char * restrict s, const char * restrict format, va_list arg); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C The vscanf(), vfscanf (), and vsscanf( ) functions shall be the same as scanf(), fscanf (), and sscanf( ) respectively, except that instead of being called with a variable number of arguments, they are called with an argument list as defined by . These functions do not invoke the va_end macro. As these functions invoke the va_arg macro, the value of ap after the return is indeterminate. RETURN VALUE Refer to fscanf(). ERRORS Referto fscanf(). EXAMPLES None. APPLICATION USAGE Applications using these functions should call va_end(ap) afterwards to clean up. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fscanf ( ), the System Interface Definitions volume of IEEE Std. 1003.1-200x, , . @ page 328 line 10396 section fgetc objection [tog-c99-xsh 230] Problem: Change required for alignment with C99 (ref C99 section 7.19.7.1). Action: Change "The fgetc( ) function obtains the next byte ..." To " If the end-of-file indicator for the input stream pointed to by stream is not set and a next character is present, the fgetc( ) function obtains the next byte ..." @ page 328 line 10405 section fgetc objection [tog-c99-xsh 231] Problem: Change required for alignment with C99 (ref C99 section 7.19.7.1). Action: Change "... If the stream is at end-of-file, ..." To "... If the end-of-file indicator for the stream is set, or if the stream is at end-of-file, ..." @ page 333 line 10519 section fgets objection [tog-c99-xsh 232] Problem: Change required for alignment with C99 (ref C99 section 7.19.7.2). Action: Change "char *fgets(char * s, int n, FILE * stream);" To "char *fgets(char * restrict s, int n, FILE * restrict stream);" @ page 378 line 12126 section fputs objection [tog-c99-xsh 233] Problem: Change required for alignment with C99 (ref C99 section 7.19.7.4). Action: Change "int fputs(const char * s, FILE * stream);" To "int fputs(const char * restrict s, FILE * restrict stream);" @ page 383 line 12294 section fread objection [tog-c99-xsh 234] Problem: Change required for alignment with C99 (ref C99 section 7.19.8.1). Action: Change "size_t fread(void * ptr, size_t size, size_t nitems, FILE * stream);" To "size_t fread(void * restrict ptr, size_t size, size_t nitems, FILE * restrict stream);" @ page 383 line 12300 section fread objection [tog-c99-xsh 235] Problem: Change required for alignment with C99 (ref C99 section 7.19.8.1). Action: Change ".., from the stream pointed to by stream. ..." To ".., from the stream pointed to by stream. For each object, size calls are made to the fgetc() function and the results stored, in the order read, in an array of unsigned char exactly overlaying the object. ..." @ page 437 line 14049 section fwrite objection [tog-c99-xsh 236] Problem: Change required for alignment with C99 (ref C99 section 7.19.8.2). Action: Change "size_t fwrite(const void *ptr, size_t size, size_t nitems, FILE * stream);" To "size_t fwrite(const void * restrict ptr, size_t size, size_t nitems, FILE * restrict stream);" @ page 437 line 14056 section fwrite objection [tog-c99-xsh 237] Problem: Change required for alignment with C99 (ref C99 section 7.19.8.2). Action: Change ".., to the stream pointed to by stream. ..." To ".., to the stream pointed to by stream. For each object, size calls are made to the fputc() function, taking the values (in order) from an array of unsigned char exactly overlaying the object. ..." @ page 331 line 10472 section fgetpos objection [tog-c99-xsh 238] Problem: Change required for alignment with C99 (ref C99 section 7.19.9.1). Action: Change "int fgetpos(FILE * stream, fpos_t * pos);" To "int fgetpos(FILE * restrict stream, fpos_t * restrict pos);" @ page 405 line 12993 section fseek objection [tog-c99-xsh 239] Problem: Change required for alignment with C99 (ref C99 section 7.19.9.2). Action: Change "The fseek( ) function shall set the file-position indicator for the stream pointed to by stream." To "The fseek( ) function shall set the file-position indicator for the stream pointed to by stream. If a read or write error occurs, the error indicator for the stream shall be set and fseek() fails. @ page 408 line 13113 section fsetpos objection [tog-c99-xsh 240] Problem: Change required for alignment with C99 (ref C99 section 7.19.9.3). Action: Add the following statement to the end of line 13113: If a read or write error occurs, the error indicator for the stream shall be set and fsetpos() fails. @ page 150 line 4756 section atoll objection [tog-c99-xsh 241] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.2). Action: Add after line 4756: long long int atoll(const char *nptr); @ page 150 line 4762 section atoll objection [tog-c99-xsh 242] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.2). Action: Add after line 4762: The call atoll(str) shall be equivalent to: strtoll(nptr, (char **)NULL, 10) @ page 150 line 4766 section atoll objection [tog-c99-xsh 243] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.2). Action: Change "The atol() function shall return ..." To "The atol() and atoll() functions shall return ..." @ page 1348 line 40895 section strtod objection [tog-c99-xsh 244] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "double strtod(const char * str, char ** endptr);" To "double strtod(const char * restrict nptr, char ** restrict endptr); float strtof(const char * restrict nptr, char ** restrict endptr); long double strtold(const char * restrict nptr, char ** restrict endptr); @ page 1348 line 40900-40901 section strtod objection [tog-c99-xsh 245] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "The strtod( ) function shall convert the initial portion of the string pointed to by str to type double representation. First it decomposes the input string into three parts: " To "The strtod(), strtof(), and strtold() functions shall convert the initial portion of the string pointed to by nptr to double, float, and long double representation, respectively. First, they decompose the input string into three parts: " @ page 1348 line 40903 section strtod objection [tog-c99-xsh 246] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "2. A subject sequence interpreted as a floating-point constant:" To "2. A subject sequence interpreted as a floating-point constant or representing infinity or Nan." @ page 1348 line 40908-40914 section strtod objection [tog-c99-xsh 247] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "The expected form of the subject sequence is an optional '+' or '-' sign, then a non-empty sequence of digits optionally containing a radix character, then an optional exponent part. An exponent part consists of e or E, followed by an optional sign, followed by one or more decimal digits. The subject sequence is defined as the longest initial subsequence of the input string, starting with the first non-white-space character that is of the expected form. The subject sequence is empty if the input string is empty or consists entirely of white-space characters, or if the first character that is not white-space is other than a sign, a digit, or a radix character. " To "The expected form of the subject sequence is an optional plus or minus sign, then one of the following: * a nonempty sequence of decimal digits optionally containing a radix character, then an optional exponent part. * a 0x or 0X, then a nonempty sequence of hexadecimal digits optionally containing a radix character, then an optional binary exponent part. * one of INF or INFINITY, ignoring case * one of NAN or NAN(n-char-sequence opt ), ignoring case in the NAN part, where: n-char-sequence: digit nondigit n-char-sequence digit n-char-sequence nondigit The subject sequence is defined as the longest initial subsequence of the input string, starting with the first non-white-space character, that is of the expected form. The subject sequence contains no characters if the input string is not of the expected form. @ page 1348 line 40915-40921 section strtod objection [tog-c99-xsh 248] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "If the subject sequence has the expected form, the sequence starting with the first digit or the radix character (whichever occurs first) is interpreted as a floating constant of the C language, except that the radix character is used in place of a period, and that if neither an exponent part nor a radix character appears, a radix character is assumed to follow the last digit in the string. If the subject sequence begins with a minus sign, the value resulting from the conversion is negated. A pointer to the final string is stored in the object pointed to by endptr, provided that endptr is not a null pointer." To "If the subject sequence has the expected form for a floating-point number, the sequence of characters starting with the first digit or the decimal-point character (whichever occurs first) is interpreted as a floating constant of the C language, except that the radix character is used in place of a period, and that if neither an exponent part nor a radix character appears in a decimal floating point number, or if a binary exponent part does not appear in a hexadecimal floating point number, an exponent part of the appropriate type with value zero is assumed to follow the last digit in the string. If the subject sequence begins with a minus sign, the sequence is interpreted as negated. A character sequence INF or INFINITY is interpreted as an infinity, if representable in the return type, else like a floating constant that is too large for the range of the return type. A character sequence NAN or NAN(n-char-sequence opt ), is interpreted as a quiet NaN, if supported in the return type, else like a subject sequence part that does not have the expected form; the meaning of the n-char sequences is implementation-dependent. A pointer to the final string is stored in the object pointed to by endptr, provided that endptr is not a null pointer. If the subject sequence has the hexadecimal form and FLT_RADIX is a power of 2, the value resulting from the conversion is correctly rounded." @ page 1349 line 40947 section strtod objection [tog-c99-xsh 249] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "None." To "If the subject sequence has the hexadecimal form and FLT_RADIX is not a power of 2, the result should be one of the two numbers in the appropriate internal format that are adjacent to the hexadecimal floating source value, with the extra stipulation that the error should have a correct sign for the current rounding direction. If the subject sequence has the decimal form and at most DECIMAL_DIG (defined in ) significant digits, the result should be correctly rounded. If the subject sequence D has the decimal form and more than DECIMAL_DIG significant digits, consider the two bounding, adjacent decimal strings L and U, both having DECIMAL_DIG significant digits, such that the values of L, D, and U satisfy L <= D <= U. The result should be one of the (equal or adjacent) values that would be obtained by correctly rounding L and U according to the current rounding direction, with the extra stipulation that the error with respect to D should have a correct sign for the current rounding direction." @ page 1349 line 40934-40937 section strtod objection [tog-c99-xsh 250] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.3). Action: Change "Upon successful completion, strtod() shall return the converted value. If no conversion could be performed, 0 shall be returned, and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, ±HUGE_VAL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. If the correct value would cause an underflow, 0 shall be returned and errno set to [ERANGE]." To "Upon successful completion, strtod(), strtof() and strtold() shall return the converted value. If no conversion could be performed, 0 shall be returned, and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, ±HUGE_VAL, ±HUGE_VALF or ±HUGE_VALL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and errno set to [ERANGE]." @ page 1354 line 41089 section strtol objection [tog-c99-xsh 251] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "long int strtol(const char * str, char **endptr, int base);" To "long int strtol(const char * restrict str, char ** restrict endptr, int base);" long long int strtoll(const char * restrict str, char ** restrict endptr, int base);" @ page 1354 line 41094-41095 section strtol objection [tog-c99-xsh 252] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "The strtol() function shall convert the initial portion of the string pointed to by str to a type long int representation. First it decomposes the input string into three parts:" To "The strtol() and strtoll() functions shall convert the initial portion of the string pointed to by str to a type long int and long long int representation, respectively. First they decompose the input string into three parts:" @ page 1355 line 41130 section strtol objection [tog-c99-xsh 253] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "Because 0, {LONG_MIN}, and {LONG_MAX} are returned on error ..." To "Because 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are returned on error ..." @ page 1355 line 41134 section strtol objection [tog-c99-xsh 254] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "Upon successful completion strtol() shall return ..." To "Upon successful completion strtol() and strtoll() shall return ..." @ page 1355 line 41136 section strtol objection [tog-c99-xsh 255] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "... {LONG_MAX} or {LONG_MIN} ..." To "... {LONG_MIN}, {LONG_MAX}, {LLONG_MIN} or {LLONG_MAX}, ..." @ page 1357 line 41183 section strtoul objection [tog-c99-xsh 256] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "long int strtoul(const char * str, char **endptr, int base);" To "long int strtoul(const char * restrict str, char ** restrict endptr, int base);" long long int strtoull(const char * restrict str, char ** restrict endptr, int base);" @ page 1357 line 41188-41189 section strtoul objection [tog-c99-xsh 257] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "The strtoul() function shall convert the initial portion of the string pointed to by str to a type long int representation. First it decomposes the input string into three parts:" To "The strtoul() and strtoull() functions shall convert the initial portion of the string pointed to by str to a type long int and long long int representation, respectively. First they decompose the input string into three parts:" @ page 1358 line 41224 section strtoul objection [tog-c99-xsh 258] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "Because 0, and {ULONG_MAX} are returned on error ..." To "Because 0, {ULONG_MAX} and {ULLONG_MAX} are returned on error ..." @ page 1358 line 41228 section strtoul objection [tog-c99-xsh 259] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "Upon successful completion strtoul() shall return ..." To "Upon successful completion strtoul() and strtoull() shall return ..." @ page 1358 line 41230 section strtoul objection [tog-c99-xsh 260] Problem: Change required for alignment with C99 (ref C99 section 7.20.1.4). Action: Change "... {ULONG_MAX} ..." To "... {ULONG_MAX} or {ULLONG_MAX}, ..." @ page 288 line 9096-9097 section exit objection [tog-c99-xsh 261] Problem: Change required for alignment with C99 (ref C99 section 7.20.4.3). Action: Change "The exit() function shall first call all functions registered by atexit (), in the reverse order of their registration. Each function is called as many times as it was registered." To "The exit() function shall first call all functions registered by atexit (), in the reverse order of their registration, except that a function is called after any previously registered functions that had already been called at the time it was registered. Each function is called as many times as it was registered. If, during the call to any such function, a call to the longjmp function is made that would terminate the call to the registered function, the behavior is undefined." @ page 292 line 9283 section _Exit objection [tog-c99-xsh 262] Problem: Change required for alignment with C99 (ref C99 section 7.20.4.4). [Ed. This page should perhaps state that _Exit() is equivalent to _exit(), and simply refer to the exit() page for the DESCRIPTION and RETURN VALUE sections. However, because of the rationale for this function on C99, I have left it as a separate page for the moment, with the text taken more or less directly from C99.] Action: Add the following entry: Name _Exit - terminate process execution without tidying up SYNOPSIS void _Exit(int status); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C The _Exit() function shall cause normal program termination to occur and control to be returned to the host environment. No functions registered by the atexit function or signal handlers registered by the signal function shall be called. The status returned to the host environment is determined in the same way as for the exit() function. Whether open streams with unwritten buffered data are flushed, open streams are closed, or temporary files are removed is implementation-dependent. RETURN VALUE The _Exit() function shall not return to its caller. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE None. RATIONALE [Ed. Below are the rationales from C89 and C99 respectively.] (1) The C Standard Committee considered the addition of _exit, but rejected it based on concerns of incompatible with the POSIX specification upon which it is based. For example, one concern expressed is that _exit was specified as a way to get out of a signal handler without triggering another signal, but that is not actually the way _exit behaves in POSIX environments. The C Standard Committee did not wish to give programmers this kind of false hope. (2) A new feature of C9X: the C9X Committee considered it desirable to have an _exit-like function that would result in immediate program termination without triggering signals or atexit-registered functions, but chose the name, _Exit, rather than _exit, because of the potential conflict with existing practice mentioned above. FUTURE DIRECTIONS None. SEE ALSO exit(), the System Interface Definitions volume of IEEE Std. 1003.1-200x, . CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 652 line 20520 section labs objection [tog-c99-xsh 263] Problem: Change required for alignment with C99 (ref C99 section 7.20.6.1). Action: Add fter line 20520: long long int llabs(long long int i); @ page 652 line 20525 section labs objection [tog-c99-xsh 264] Problem: Change required for alignment with C99 (ref C99 section 7.20.6.1). Action: Change "The labs() function ..." To "The labs() and llabs() functions ..." Same change on line 20528. @ page 658 line 20667 section ldiv objection [tog-c99-xsh 265] Problem: Change required for alignment with C99 (ref C99 section 7.20.6.2). Action: Add after line 20667: lldiv_t lldiv(long long int numer, long long int denom); @ page 658 line 20672 section ldiv objection [tog-c99-xsh 266] Problem: Change required for alignment with C99 (ref C99 section 7.20.6.2). Action: Change "The ldiv() function ..." To "The ldiv() and lldiv() functions ..." Same change on line 20677. @ page 710 line 22280 section mbtowc objection [tog-c99-xsh 267] Problem: Change required for alignment with C99 (ref C99 section 7.20.7.2). Action: Change "int mbtowc(wchar_t * pwc, const char * s, size_t n);" To "int mbtowc(wchar_t * restrict pwc, const char * restrict s, size_t n);" @ page 1523 line 46324 section wctomb objection [tog-c99-xsh 268] Problem: Change required for alignment with C99 (ref C99 section 7.20.7.2). Action: Change "... If wchar is 0, wctomb( ) is left in the initial shift state." To "... If wchar is 0, a null byte is stored, preceded by any shift sequence needed to restore the initial shift state, and wctomb( ) is left in the initial shift state." @ page 709 line 22238 section mbstowcs objection [tog-c99-xsh 269] Problem: Change required for alignment with C99 (ref C99 section 7.20.8.1). Action: Change "size_t mbstowcs(wchar_t * pwcs, const char * s, size_t n);" To "size_t mbstowcs(wchar_t * restrict pwcs, const char * restrict s, size_t n);" @ page 1514 line 46023 section wcstombs objection [tog-c99-xsh 270] Problem: Change required for alignment with C99 (ref C99 section 7.20.8.2). Action: Change "size_t wcstombs(char * s, const wchar_t * pwcs, size_t n);" To "size_t wcstombs(char * restrict s, const wchar_t * restrict pwcs, size_t n);" @ page 715 line 22435 section memcpy objection [tog-c99-xsh 271] Problem: Change required for alignment with C99 (ref C99 section 7.21.2.1). Action: Change "void *memcpy(void * s1, const void * s2, size_t n);" To "void *memcpy(void * restrict s1, const void * restrict s2, size_t n);" @ page 1318 line 39934 section strcpy objection [tog-c99-xsh 272] Problem: Change required for alignment with C99 (ref C99 section 7.21.2.3). Action: Change "char *strcpy(char * s1, const char * s2);" To "char *strcpy(char * restrict s1, const char * restrict s2);" @ page 1338 line 40580 section strncpy objection [tog-c99-xsh 273] Problem: Change required for alignment with C99 (ref C99 section 7.21.2.4). Action: Change "char *strncpy(char * s1, const char * s2, size_t n);" To "char *strncpy(char * restrict s1, const char * restrict s2, size_t n);" @ page 1312 line 39728 section strcat objection [tog-c99-xsh 274] Problem: Change required for alignment with C99 (ref C99 section 7.21.3.1). Action: Change "char *strcat(char * s1, const char * s2);" To "char *strcat(char * restrict s1, const char * restrict s2);" @ page 1336 line 40504 section strncat objection [tog-c99-xsh 275] Problem: Change required for alignment with C99 (ref C99 section 7.21.3.2). Action: Change "char *strncat(char * s1, const char * s2, size_t n);" To "char *strncat(char * restrict s1, const char * restrict s2, size_t n);" @ page 1359 line 41265 section strxfrm objection [tog-c99-xsh 276] Problem: Change required for alignment with C99 (ref C99 section 7.21.4.5). Action: Change "size_t strxfrm(char * s1, const char * s2, size_t n);" To "size_t strxfrm(char * restrict s1, const char * restrict s2, size_t n);" @ page 1351 line 40981 section strtok objection [tog-c99-xsh 277] Problem: Change required for alignment with C99 (ref C99 section 7.21.5.8). [Ed. strtok_r should probably be changed as well, but I have avoided adding the "restrict" type-qualifier to any none c99 functions. This area probably requires review by the working group.] Action: Change "char *strtok(char * s1, const char * s2);" To "char *strtok(char * restrict s1, const char * restrict s2);" @ page 1328 line 40275-40276 section strftime objection [tog-c99-xsh 278] Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Change "size_t strftime(char * s, size_t maxsize, const char * format, const struct tm * timptr); To "size_t strftime(char * restrict s, size_t maxsize, const char * restrict format, const struct tm * restrict timptr); @ page 1328 line 40283-40284 section strftime objection [tog-c99-xsh 279] Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Change "A conversion specification consists of a '%' character and a terminating conversion character that determines the conversion specification's behavior." To "A conversion specification consists of a '%' character, possibly followed by an E or O modifier, and a terminating conversion character that determines the conversion specification’s behavior." @ page 1328-1329 line 40291-40333 section strftime objection [tog-c99-xsh 280] Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Remove CX shading from the following consversion specifiers: %C, %D, %e, %h, %n, %r, %R, %t and %T. And add the following conversion specifiers to the table on lines 40291-40333: %F is equivalent to "%Y-%m-%d" (the ISO 8601 date format). %g is replaced by the last 2 digits of the week-based year (see below) as a decimal number (00-99). %G is replaced by the week-based year (see below) as a decimal number (e.g., 1997). %z is replaced by the offset from UTC in the ISO 8601 format "-0430" (meaning 4 hours 30 minutes behind UTC, west of Greenwich), or by no characters if no time zone is determinable. @ page 1330 line 40372 section strftime objection [tog-c99-xsh 281] Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Add after line 40372: %g, %G, and %V give values according to the ISO 8601 week-based year. In this system, weeks begin on a Monday and week 1 of the year is the week that includes January 4th, which is also the week that includes the first Thursday of the year, and is also the first week that contains at least four days in the year. If the first Monday of January is the 2nd, 3rd, or 4th, the preceding days are part of the last week of the preceding year; thus, for Saturday 2nd January 1999, %G is replaced by 1998 and %V is replaced by 53.If December 29th, 30th, or 31st is a Monday, it and any following days are part of week 1 of the following year. Thus, for Tuesday 30th December 1997, %G is replaced by 1998 and %V is replaced by 01. If a conversion specifier is not one of the above, the behavior is undefined. @ page 1331 line 40403 section strftime objection [tog-c99-xsh 282] Problem: Change required for alignment with C99 (ref C99 section 7.23.3.5). Action: Add after line 40403: In the "C" locale, the E and O modifiers are ignored and the replacement strings for the following specifiers are: %a the first three characters of %A. %A one of Sunday , Monday, ... , Saturday. %b the first three characters of %B. %B one of January , February, ... , December . %c equivalent to "%a %b %e %T %Y" . %p one of "AM" or "PM". %r equivalent to "%I:%M:%S %p" . %x equivalent to "%m/%d/%y" . %X equivalent to %T. %Z implementation-dependent. @ page 431 line 13815-13817 section fwprintf objection [tog-c99-xsh 283] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "int fwprintf(FILE * stream, const wchar_t * format, ...); int swprintf(wchar_t *s, size_t n, const wchar_t * format, ...); int wprintf(const wchar_t * format, ...);" To "int fwprintf(FILE * restrict stream, const wchar_t * restrict format, ...); int swprintf(wchar_t * restrict s, size_t n, const wchar_t * restrict format, ...); int wprintf(const wchar_t * restrict format, ...);" @ page 432 line 13862-13874 section fwprintf objection [tog-c99-xsh 284] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change lines 13862-13874 to contain only the following text: "* An optional length modifier that specifies the size of the argument." @ page 433 line 13918 section fwprintf objection [tog-c99-xsh 285] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Add the following text after line 13918: The length modifiers and their meanings are: hh Specifies that a following d, i, o, u, x,or X conversion specifier applies to a signed char or unsigned char argument (the argument will have been promoted according to the integer promotions, but its value shall be converted to signed char or unsigned char before printing); or that a following n conversion specifier applies to a pointer to a signed char argument. h Specifies that a following d, i, o, u, x,or X conversion specifier applies to a short int or unsigned short int argument (the argument will have been promoted according to the integer promotions, but its value shall be converted to short int or unsigned short int before printing); or that a following n conversion specifier applies to a pointer to a short int argument. l (ell) Specifies that a following d, i, o, u, x,or X conversion specifier applies to a long int or unsigned long int argument; that a following n conversion specifier applies to a pointer to a long int argument; that a following c conversion specifier applies to a wint_t argument; that a following s conversion specifier applies to a pointer to a wchar_t argument; or has no effect on a following a, A, e, E, f, F, g,orGconversion specifier. ll (ell-ell) Specifies that a following d, i, o, u, x,or X conversion specifier applies to a long long int or unsigned long long int argument; or that a following n conversion specifier applies to a pointer to a long long int argument. j Specifies that a following d, i, o, u, x, or X conversion specifier applies to an intmax_t or uintmax_t argument; or that a following n conversion specifier applies to a pointer to an intmax_t argument. z Specifies that a following d, i, o, u, x,orXconversion specifier applies to a size_t or the corresponding signed integer type argument; or that a following n conversion specifier applies to a pointer to a signed integer type corresponding to size_t argument. t Specifies that a following d, i, o, u, x,or X conversion specifier applies to a ptrdiff_t or the corresponding unsigned integer type argument; or that a following n conversion specifier applies to a pointer to a ptrdiff_t argument. L Specifies that a following a, A, e, E, f, F, g,or G conversion specifier applies to a long double argument. If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. @ page 433 line 13942 section fwprintf objection [tog-c99-xsh 286] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "f A double argument ..." To "f,F A double argument ..." @ page 433 line 13947-13948 section fwprintf objection [tog-c99-xsh 287] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "The fwprintf () family of functions may make available character string representations for infinity and NaN." To "A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity - which style is implementation-dependent. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-dependent. The F conversion specifier produces INF, INFINITY,orNAN instead of inf, infinity,ornan, respectively." And remove the XSI margin mark. @ page 434 line 13956-13957 section fwprintf objection [tog-c99-xsh 288] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "The fwprintf () family of functions may make available character string representations for infinity and NaN." To " A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier." And remove the XSI margin mark. @ page 434 line 13965-13966 section fwprintf objection [tog-c99-xsh 289] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "The fwprintf () family of functions may make available character string representations for infinity and NaN." To " A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier." And remove the XSI margin mark. @ page 434 line 13966 section fwprintf objection [tog-c99-xsh 290] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Add the folowing text after line 13966: a,A A double argument representing a floating-point number is converted in the style [-]0xh.hhhh p±d, where there is one hexadecimal digit (which is nonzero if the argument is a normalized floating-point number and is otherwise unspecified) before the decimal-point character 235) and the number of hexadecimal digits after it is equal to the precision; if the precision is missing and FLT_RADIX is a power of 2, then the precision is sufficient for an exact representation of the value; if the precision is missing and FLT_RADIX is not a power of 2, then the precision is sufficient to distinguish 236) values of type double, except that trailing zeros may be omitted; if the precision is zero and the # flag is not specified, no decimal-point character appears. The letters abcdef are used for a conversion and the letters ABCDEF for A conversion. The A conversion specifier produces a number with X and P instead of x and p. The exponent always contains at least one digit, and only as many more digits as necessary to represent the decimal exponent of 2. If the value is zero, the exponent is zero. A double argument representing an infinity or NaN is converted in the style of an f or F conversion specifier. @ page 434 line 13990 section fwprintf objection [tog-c99-xsh 291] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Change "No argument is converted." To "No argument is converted. No argument is converted, but one is consumed. If the conversion specification includes any flags, a field width, or a precision, the behavior is undefined." @ page 435 line 13999 section fwprintf objection [tog-c99-xsh 292] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.1). Action: Add after line 13999: For a and A conversions, if FLT_RADIX is a power of 2, the value is correctly rounded to a hexadecimal floating number with the given precision. If FLT_RADIX is not a power of 2, the result should be one of the two adjacent numbers in hexadecimal floating style with the given precision, with the extra stipulation that the error should have a correct sign for the current rounding direction. For e, E, f, F, g, and G conversions, if the number of significant decimal digits is at most DECIMAL_DIG, then the result should be correctly rounded. If the number of significant decimal digits is more than DECIMAL_DIG but the source value is exactly representable with DECIMAL_DIG digits, then the result should be an exact representation with trailing zeros. Otherwise, the source value is bounded by two adjacent decimal strings L < U, both having DECIMAL_DIG significant digits; the value of the resultant decimal string D should satisfy L <= D <= U, with the extra stipulation that the error should have a correct sign for the current rounding direction. @ page 439 line 14098-14100 section fwscanf objection [tog-c99-xsh 293] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Change "int fwscanf(FILE * stream, const wchar_t * format, ... ); int swscanf(const wchar_t * s, const wchar_t * format, ... ); int wscanf(const wchar_t * format, ... );" To "int fwscanf(FILE * restrict stream, const wchar_t * restrict format, ... ); int swscanf(const wchar_t * restrict s, const wchar_t * restrict format, ... ); @ page 439-440 line 14134-14144 section fwscanf objection [tog-c99-xsh 294] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Change lines 14134-14144 to contain only the following text: "* An optional length modifier that specifies the size of the receiving object." @ page 440 line 14156 section fwscanf objection [tog-c99-xsh 295] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Add to the end of line 14156: Similarly, if end-of-file, an encoding error, or a read error prevents a wide character from being read, the directive fails. @ page 440 line 14178 section fwscanf objection [tog-c99-xsh 296] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Add the following text after line 14178: The length modifiers and their meanings are: hh Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to signed char or unsigned char. h Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to short int or unsigned short int. l (ell) Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to long int or unsigned long int; that a following a, A, e, E, f, F, g,orGconversion specifier applies to an argument with type pointer to double; or that a following c, s,or[ conversion specifier applies to an argument with type pointer to wchar_t. ll (ell-ell) Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to long long int or unsigned long long int. j Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to intmax_t or uintmax_t. z Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to size_t or the corresponding signed integer type. t Specifies that a following d, i, o, u, x, X,ornconversion specifier applies to an argument with type pointer to ptrdiff_t or the corresponding unsigned integer type. L Specifies that a following a, A, e, E, f, F, g,orGconversion specifier applies to an argument with type pointer to long double. If a length modifier appears with any conversion specifier other than as specified above, the behavior is undefined. @ page 441 line 14200 section fwscanf objection [tog-c99-xsh 297] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Change "e,f g Matches an optionally signed floating-point number, whose format is the same as ..." To "a,e,f g Matches an optionally signed floating-point number, infinity or NaN, whose format is the same as ..." @ page 442 line 14259 section fwscanf objection [tog-c99-xsh 298] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Add to the end of line 14259: No argument is converted, but one is consumed. If the conversion specification includes an assignment-suppressing wide character or a field width, the behavior is undefined. @ page 442 line 14265 section fwscanf objection [tog-c99-xsh 299] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.2). Action: Change "The conversion characters E, G, and X are also valid and behave the same as, respectively, e, g, and x." To "The conversion characters A, E, F, G and X are also valid and behave the same as, respectively, a, e, f, g, and x." @ page 1476 line 44790-44793 section vfwprintf objection [tog-c99-xsh 300] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.5). Action: Change "int vfwprintf(FILE * stream, const wchar_t * format, va_list arg); int vswprintf(wchar_t * s, size_t n, const wchar_t * format, va_list arg); int vwprintf(const wchar_t * format, va_list arg);" To "int vfwprintf(FILE * restrict stream, const wchar_t * restrict format, va_list arg); int vswprintf(wchar_t * restrict s, size_t n, const wchar_t * restrict format, va_list arg); int vwprintf(const wchar_t * restrict format, va_list arg); @ page 1476 line 44820 section vfwscanf objection [tog-c99-xsh 301] Problem: Change required for alignment with C99 (ref C99 section 7.23.2.6). Action: Add the following entry after line 44820 NAME vfwscanf - wide-character formattted input of a stdarg list SYNOPSIS #include #include #include int vfwscanf(FILE * restrict stream, const wchar_t * restrict format, va_list arg); int vswscanf(const wchar_t * restrict s, const wchar_t * restrict format, va_list arg); int vwscanf(const wchar_t * restrict format, va_list arg); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C The vfwscanf(), vswscanf (), and vwscanf( ) functions shall be the same as fwscanf(), swscanf (), and wscanf( ) respectively, except that instead of being called with a variable number of arguments, they are called with an argument list as defined by . These functions do not invoke the va_end macro. As these functions invoke the va_arg macro, the value of ap after the return is indeterminate. RETURN VALUE Refer to fwscanf(). ERRORS Referto fwscanf(). EXAMPLES None. APPLICATION USAGE Applications using these functions should call va_end(ap) afterwards to clean up. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO fwscanf ( ), the System Interface Definitions volume of IEEE Std. 1003.1-200x, , . @ page 337 line 10644 section fgetws objection [tog-c99-xsh 302] Problem: Change required for alignment with C99 (ref C99 section 7.23.3.2). Action: Change "wchar_t *fgetws(wchar_t * ws, int n, FILE * stream);" To "wchar_t *fgetws(wchar_t * restrict ws, int n, FILE * restrict stream);" @ page 382 line 12257 section fputws objection [tog-c99-xsh 303] Problem: Change required for alignment with C99 (ref C99 section 7.23.3.4). Action: Change "int fputws(const wchar_t * ws, FILE * stream);" To "int fputws(const wchar_t * restrict ws, FILE * restrict stream);" @ page 1508 line 45808 section wcstod objection [tog-c99-xsh 304] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "double wcstod(const wchar_t * nptr, wchar_t ** endptr);" To "double wcstod(const wchar_t * restrict nptr, wchar_t ** restrict endptr); float wcstof(const wchar_t * restrict nptr, wchar_t ** restrict endptr); long double wcstold(const wchar_t * restrict nptr, wchar_t ** restrict endptr);" @ page 1508 line 45813-45814 section wcstod objection [tog-c99-xsh 305] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "The wcstod( ) function shall convert the initial portion of the string pointed to by nptr to type double representation. First it decomposes the input wide-character string into three parts: " To "The wcstod(), wcstof(), and wcstold() functions shall convert the initial portion of the wide string pointed to by nptr to double, float, and long double representation, respectively. First, they decompose the input string into three parts: " @ page 1508 line 45818 section wcstod objection [tog-c99-xsh 306] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "2. A subject sequence interpreted as a floating-point constant:" To "2. A subject sequence interpreted as a floating-point constant or representing infinity or Nan." @ page 1508 line 45823-45830 section wcstod objection [tog-c99-xsh 307] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "The expected form of the subject sequence is an optional '+' or '-' sign, then a non-empty sequence of digits optionally containing a radix character, then an optional exponent part. An exponent part consists of 'e' or 'E', followed by an optional sign, followed by one or more decimal digits. The subject sequence is defined as the longest initial subsequence of the input wide-character string, starting with the first non-white-space wide-character code, that is of the expected form. The subject sequence contains no wide-character codes if the input wide-character string is empty or consists entirely of white-space wide-character codes, or if the first wide-character code that is not white space other than a sign, a digit, or a radix character. To "The expected form of the subject sequence is an optional plus or minus sign, then one of the following: * a nonempty sequence of decimal digits optionally containing a radix character, then an optional exponent part. * a 0x or 0X, then a nonempty sequence of hexadecimal digits optionally containing a radix character, then an optional binary exponent part. * one of INF or INFINITY, or any other wide string equivalent except for case. * one of NAN or NAN(n-wchar-sequence opt ), or any other wide string equivalent except for case in the NAN part, where: n-wchar-sequence: digit nondigit n-wchar-sequence digit n-wchar-sequence nondigit The subject sequence is defined as the longest initial subsequence of the input wide string, starting with the first non-white-space wide character, that is of the expected form. The subject sequence contains no wide characters if the input wide string is not of the expected form. @ page 1508 line 45831-45837 section wcstod objection [tog-c99-xsh 308] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "If the subject sequence has the expected form, the sequence of wide-character codes starting with the first digit or the radix character (whichever occurs first) is interpreted as a floating constant as defined in the C language, except that the radix character is used in place of a period, and that if neither an exponent part nor a radix character appears, a radix character is assumed to follow the last digit in the wide-character string. If the subject sequence begins with a minus 45836 sign, the value resulting from the conversion is negated. A pointer to the final wide-character string is stored in the object pointed to by endptr, provided that endptr is not a null pointer." To "If the subject sequence has the expected form for a floating-point number, the sequence of wide characters starting with the first digit or the radix character (whichever occurs first) is interpreted as a floating constant according to the rules of the C language, except that the radix character is used in place of a period, and that if neither an exponent part nor a radix character appears in a decimal floating point number, or if a binary exponent part does not appear in a hexadecimal floating point number, an exponent part of the appropriate type with value zero is assumed to follow the last digit in the string. If the subject sequence begins with a minus sign, the sequence is interpreted as negated. A wide character sequence INF or INFINITY is interpreted as an infinity, if representable in the return type, else like a floating constant that is too large for the range of the return type. A wide character sequence NAN or NAN(n-wchar-sequence opt ) is interpreted as a quiet NaN, if supported in the return type, else like a subject sequence part that does not have the expected form; the meaning of the n-wchar sequences is implementation-dependent. A pointer to the final wide string is stored in the object pointed to by endptr, provided that endptr is not a null pointer. If the subject sequence has the hexadecimal form and FLT_RADIX is a power of 2, the value resulting from the conversion is correctly rounded." @ page 1509 line 45863 section wcstod objection [tog-c99-xsh 309] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "None." To "If the subject sequence has the hexadecimal form and FLT_RADIX is not a power of 2, the result should be one of the two numbers in the appropriate internal format that are adjacent to the hexadecimal floating source value, with the extra stipulation that the error should have a correct sign for the current rounding direction. If the subject sequence has the decimal form and at most DECIMAL_DIG (defined in ) significant digits, the result should be correctly rounded. If the subject sequence D has the decimal form and more than DECIMAL_DIG significant digits, consider the two bounding, adjacent decimal strings L and U, both having DECIMAL_DIG significant digits, such that the values of L, D, and U satisfy L <= D <= U. The result should be one of the (equal or adjacent) values that would be obtained by correctly rounding L and U according to the current rounding direction, with the extra stipulation that the error with respect to D should have a correct sign for the current rounding direction." @ page 1509 line 45850-45854 section wcstod objection [tog-c99-xsh 310] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.1). Action: Change "Upon successful completion, wcstod() shall return the converted value. If no conversion could be performed, 0 shall be returned, and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, ±HUGE_VAL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. If the correct value would cause an underflow, 0 shall be returned and errno set to [ERANGE]." To "Upon successful completion, wcstod(), wcstof() and wcstold() shall return the converted value. If no conversion could be performed, 0 shall be returned, and errno may be set to [EINVAL]. If the correct value is outside the range of representable values, ±HUGE_VAL, ±HUGE_VALF or ±HUGE_VALL shall be returned (according to the sign of the value), and errno shall be set to [ERANGE]. If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and errno set to [ERANGE]." @ page 1512 line 45938 section wcstol objection [tog-c99-xsh 311] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "long int wcstol(const wchar_t * nptr, wchar_t **endptr, int base);" To "long int wcstol(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); long long int wcstoll( const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base);" @ page 1512 line 45943-45945 section wcstol objection [tog-c99-xsh 312] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "The wcstol( ) function shall convert the initial portion of the wide-character string pointed to by nptr to long int representation. First it decomposes the input wide-character string into three parts:" To "The wcstol() and wcstoll() functions shall convert the initial portion of the wide string pointed to by nptr to long int, long long int, unsigned long int, and unsigned long long int representation, respectively. First, they decompose the input string into three parts: @ page 1513 line 45983 section wcstol objection [tog-c99-xsh 313] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "Because 0, {LONG_MIN}, and {LONG_MAX} are returned on error ..." To "Because 0, {LONG_MIN} or {LLONG_MIN}, and {LONG_MAX} or {LLONG_MAX} are returned on error ..." @ page 1513 line 45987 section wcstol objection [tog-c99-xsh 314] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "... wcstol() ..." To "... wcstol() and wcstoll() ..." Same change of lines 45992 and 45995. @ page 1516 line 46071 section wcstoul objection [tog-c99-xsh 315] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "long int wcstoul(const wchar_t * nptr, wchar_t **endptr, int base);" To "long int wcstoul(const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base); long long int wcstoull( const wchar_t * restrict nptr, wchar_t ** restrict endptr, int base);" @ page 1516 line 56077-46079 section wcstoul objection [tog-c99-xsh 316] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "The wcstoul() function shall convert the initial portion of the wide-character string pointed to by nptr to long int representation. First it decomposes the input wide-character string into three parts:" To "The wcstoul() and wcstoull() functions shall convert the initial portion of the wide string pointed to by nptr to long int, long long int, unsigned long int, and unsigned long long int representation, respectively. First, they decompose the input string into three parts: @ page 1517 line 46116 section wcstoul objection [tog-c99-xsh 317] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "Because 0 and {ULONG_MAX} are returned on error ..." To "Because 0, {ULONG_MAX} and {ULLONG_MAX} are returned on error ..." @ page 1517 line 46120 section wcstoul objection [tog-c99-xsh 318] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.1.2). Action: Change "... wcstoul() ..." To "... wcstoul() and wcstoull() ..." Same change of lines 46125 and 46128. @ page 1495 line 45386 section wcscpy objection [tog-c99-xsh 319] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.2.1). Action: Change "wchar_t *wcscpy(wchar_t * ws1, const wchar_t * ws2);" To "wchar_t *wcscpy(wchar_t * restrict ws1, const wchar_t * restrict ws2);" @ page 1501 line 45585 section wcsncpy objection [tog-c99-xsh 320] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.2.2). Action: Change "wchar_t *wcsncpy(wchar_t * ws1, const wchar_t * ws2, size_t n);" To "wchar_t *wcsncpy(wchar_t * restrict ws1, const wchar_t * restrict ws2, size_t n);" @ page 1531 line 46558 section wmemcpy objection [tog-c99-xsh 321] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.2.3). Action: Change "wchar_t *wmemcpy(wchar_t * ws1, const wchar_t * ws2, size_t n);" To "wchar_t *wmemcpy(wchar_t * restrict ws1, const wchar_t * restrict ws2, size_t n);" @ page 1491 line 45245 section wcscat objection [tog-c99-xsh 322] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.3.1). Action: Change "wchar_t *wcscat(wchar_t * ws1, const wchar_t * ws2);" To "wchar_t *wcscat(wchar_t * restrict ws1, const wchar_t * restrict ws2);" @ page 1499 line 45520 section wcsncat objection [tog-c99-xsh 323] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.3.2). Action: Change "wchar_t *wcsncat(wchar_t * ws1, const wchar_t * ws2, size_t n);" To "wchar_t *wcsncat(wchar_t * restrict ws1, const wchar_t * restrict ws2, size_t n);" @ page 1520 line 46226 section wcsxfrm objection [tog-c99-xsh 324] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.4.4). Action: Change "size_t wcsxfrm(wchar_t * ws1, const wchar_t * ws2, size_t n);" To "size_t wcsxfrm(wchar_t * restrict ws1, const wchar_t * restrict ws2, size_t n);" @ page 1507 line 45777 section wcsstr objection [tog-c99-xsh 325] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.5.6). Action: Change "wchar_t *wcsstr(const wchar_t * ws1, const wchar_t * ws2);" To "wchar_t *wcsstr(const wchar_t * restrict ws1, const wchar_t * restrict ws2);" @ page 1510 line 45887 section wcstok objection [tog-c99-xsh 326] Problem: Change required for alignment with C99 (ref C99 section 7.24.4.5.7). Action: Change "wchar_t *wcstok(wchar_t * ws1, const wchar_t * ws2, wchar_t **ptr);" To "wchar_t *wcstok(wchar_t * restrict ws1, const wchar_t * restrict ws2, wchar_t ** restrict ptr);" @ page 1497 line 45449-45450 section wcsftime objection [tog-c99-xsh 327] Problem: Change required for alignment with C99 (ref C99 section 7.24.5.1). Action: Change "size_t wcsftime(wchar_t * wcs, size_t maxsize, const wchar_t * format, const struct tm * timptr); " To "size_t wcsftime(wchar_t * restrict wcs, size_t maxsize, const wchar_t * restrict format, const struct tm * restrict timptr); " @ page 1522 line 46295 section wctob objection [tog-c99-xsh 328] Problem: Change required for alignment with C99 (ref C99 section 7.24.6.1.2). Action: Change "Otherwise, it shall return the single-byte representation of that character." To "Otherwise, it shall return the single-byte representation of that character as an unsigned char converted to int." @ page 702 line 22039 section mbrlen objection [tog-c99-xsh 329] Problem: Change required for alignment with C99 (ref C99 section 7.24.6.3.1). Action: Change "size_t mbrlen(const char * s, size_t n, mbstate_t * ps);" To "size_t mbrlen(const char * restrict s, size_t n, mbstate_t * restrict ps);" @ page 704 line 22090 section mbrtowc objection [tog-c99-xsh 330] Problem: Change required for alignment with C99 (ref C99 section 7.24.6.3.2). Action: Change "size_t mbrtowc(wchar_t * pwc, const char * s, size_t n, mbstate_t * ps);" Change "size_t mbrtowc(wchar_t * restrict pwc, const char * restrict s, size_t n, mbstate_t * restrict ps);" @ page 1489 line 45192 section wcrtomb objection [tog-c99-xsh 331] Problem: Change required for alignment with C99 (ref C99 section 7.24.6.3.3). Action: Change "size_t wcrtomb(char * s, wchar_t wc, mbstate_t * ps);" To "size_t wcrtomb(char * restrict s, wchar_t wc, mbstate_t * restrict ps);" @ page 707 line 22185-22186 section mbsrtowcs objection [tog-c99-xsh 332] Problem: Change required for alignment with C99 (ref C99 section 7.24.6.4.1). Action: Change "size_t mbsrtowcs(wchar_t * dst, const char ** src, size_t len, mbstate_t * ps);" To "size_t mbsrtowcs(wchar_t * restrict dst, const char ** restrict src, size_t len, mbstate_t * restrict ps);" @ page 1504 line 45683-45684 section wcsrtombs objection [tog-c99-xsh 333] Problem: Change required for alignment with C99 (ref C99 section 7.24.6.4.2). Action: Change "size_t wcsrtombs(char * dst, const wchar_t ** src, size_t len, mbstate_t * ps);" To "size_t wcsrtombs(char * restrict dst, const wchar_t ** restrict src, size_t len, mbstate_t * restrict ps);" @ page 624 line 19804 section iswblank objection [tog-c99-xsh 334] Problem: Change required for alignment with C99 (ref C99 section 7.25.2.1.3). Action: Add the following entry after line 19804: NAME iswblank - test for a blank wide-character code SYNOPSIS #include int iswblank(wint_t wc); DESCRIPTION The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std. 1003.1-200x defers to the ISO C The iswblank() function shall test whether wc is a wide-character code representing a character of class blank in the program’s current locale; see the System Interface Definitions volume of IEEE Std. 1003.1-200x, Chapter 7, Locale. In all cases wc is a wint_t, the value of which the application shall ensure is a wide-character code corresponding to a valid character in the current locale, or equal to the value of the macro WEOF. If the argument has any other value, the behavior is undefined. RETURN CODE The iswblank() function shall return non-zero if wc is a blank wide-character code; otherwise, it shall return 0. ERRORS No errors are defined. EXAMPLES None. APPLICATION USAGE To ensure applications portability, especially across natural languages, only this function and those listed in the SEE ALSO section should be used for classification of wide-character codes. RATIONALE None. FUTURE DIRECTIONS None. SEE ALSO iswalnum(), iswalpha(), iswcntrl(), iswctype(), iswdigit (), iswgraph(), iswlower(), iswprint(), iswpunct(), iswspace(), iswupper(), iswxdigit (), setlocale ( ), the System Interface Definitions volume of IEEE Std. 1003.1-200x, , , , the System Interface Definitions volume of IEEE Std. 1003.1-200x, Chapter 7, Locale CHANGE HISTORY First released in Issue 6. Entry included for alignment with C99. @ page 627 line 19884 section iswctype objection [tog-c99-xsh 335] Problem: Change required for alignment with C99 (ref C99 section 7.25.2.2.1). Action: Add after line 19884: iswblank(wc) iswctype( wc, wctype("blank")) @ page 32 line 914-944 section 2.2 objection [tog-c99-xsh 336] Problem: Change required for alignment with C99. Action: Add the following identifiers to the table on lines 914-944: _Exit acosh acoshf acoshl acosl asinh asinhf asinhl asinl atanf atanh atanh atanhf atanhl atanl atoll cabs cabsf cabsl cacos cacosf cacosh cacoshf cacoshl cacosl carg cargf cargl casin casinf casinh casinhf casinhl casinl catan catanf catanh catanh catanhf catanhf catanhl catanhl catanl cbrt cbrtf cbrtl ccos ccosf ccosh ccoshf ccoshl ccosl ceilf ceill cexp cexpf cexpl cimag cimagf cimagl clog clogf clogl conj conjf conjl copysign copysignf copysignl cpow cpowf cpowl cproj cprojf cprojl creal crealf creall csin csinf csinh csinhf csinhl csinl csqrt csqrtf csqrtl ctan ctanf ctanl erfcf erfcl erff erfl exp2 exp2f exp2l expm1 expm1f expm1l fdim fdimf fdiml feclearexcept fegetenv fegetexceptflag fegetround feholdexcept feraiseexcept fesetenv fesetexceptflag fesetround fetestexcept feupdateenv fma fmaf fmal fmax fmaxf fmaxl fmin fminf fminl hypotf hypotl ilogb ilogbf ilogbl imaxabs imaxdiv isblank iswblank ldiv lgammaf lgammal llabs llrint llrintf llrintl llround llroundf llroundl log1p log1pf log1pl log2 log2f log2l logb logbf logbl lrint lrintf lrintl lround lroundf lroundl nan nanf nanl nearbyint nearbyintf nearbyintl nextafterf nextafterl nexttoward nexttowardf nexttowardl remainderf remainderl remquo remquof remquol rint rintf rintl round roundf roundl scalbln scalblnf scalblnl scalbn scalbnf scalbnl strtof strtoimax strtold strtoll strtoull strtoumax tgamma tgammaf tgammal trunc truncf truncl vfscanf vfwscanf vscanf vsscanf vswscanf vwscanf wcstof wcstoimax wcstold wcstoll wcstoull wcstoumax @ page 33 line 955-980 section 2.2 objection [tog-c99-xsh 337] Problem: Change required for alignment with C99. Action: Remove the following identifiers from the table on line 955-980. These functions are now defined in C99 and should no longer be marked XSI: acosh asinh atanh expm1 ilogb log1p logb rint The XSI markings should also be removed from the associated man page entries in section 3.