Mail Archives: djgpp-workers/2004/01/13/10:35:15
--part1_5f.43e4a8d9.2d356a0e_boundary
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
In reviewing my code for the long double functions, I've referred
to specifications in both C99 [ISO/IEC 9899:1999 (E)] and Posix,
at http://www.opengroup.org/onlinepubs/007904975/. There are
wide discrepancies in these documents for the llrint functions.
Paragraph 7.12.9.5 of ISO/IEC 9899:1999 (E) states:
>
> The lrint and llrint functions round their argument to the
> nearest integer value, rounding according to the current
> rounding direction. If the rounded value is outside the
> range of the return type, the numeric result is unspecified.
> A range error may occur if the magnitude of x is too large.
>=20
Further, in paragraph F.9.6.5 is the following:
>=20
> The lrint and llrint functions provide floating-to-integer=20
> conversion as prescribed by IEC 60559. They round according=20
> to the current rounding direction. If the rounded value is=20
> outside the range of the return type, the numeric result is=20
> unspecified and the invalid exception is raised. When they=20
> raise no other exception and the result differs from the=20
> argument, they raise the inexact exception.
In the Posix document for llrint, llrintf, and llrintl are the=20
following specifications:
> These functions shall round their argument to the nearest=20
> integer value, rounding according to the current rounding=20
> direction.
>=20
> An application wishing to check for error situations should=20
> set errno to zero and call feclearexcept(FE_ALL_EXCEPT) before=20
> calling these functions. On return, if errno is non-zero or=20
> fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW)=20
> is non-zero, an error has occurred.
>=20
> RETURN VALUE
> Upon successful completion, these functions shall return the=20
> rounded integer value.
>=20
> If x is NaN, a domain error shall occur, and an unspecified value is=20
returned.
> If x is +Inf, a domain error shall occur and an unspecified value is=20
returned.
> If x is -Inf, a domain error shall occur and an unspecified value is=20
returned.
> If the correct value is positive and too large to represent as a long long=
,=20
> a domain error shall occur and an unspecified value is returned.
>=20
> If the correct value is negative and too large to represent as a long long=
,=20
> a domain error shall occur and an unspecified value is returned.=20
>=20
> ERRORS
> These functions shall fail if:
>=20
> Domain Error=20
> The x argument is NaN or =B1Inf, or the correct value is not representable=
=20
> as an integer. If the integer expression (math_errhandling & MATH_ERRNO)=20
> is non-zero, then errno shall be set to [EDOM]. If the integer expression=20
> (math_errhandling & MATH_ERREXCEPT) is non-zero, the invalid floating-poin=
t=20
> exception shall be raised.=20
>=20
So, C99 says return a range error if the rounded result is too large,
whereas Posix requires a domain error regardless of the kind of error.
Which way is the right way? The code, written a couple of years ago,=20
proceeds as follows:
If the argument is a NaN, set domain error [EDOM]. If the rounded=20
result is too large (including +- Inf), set range error [ERANGE].
In both cases, the invalid floating-point exception is raised.
KB Williams
--part1_5f.43e4a8d9.2d356a0e_boundary
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><FONT FACE=3Darial,helvetica><HTML><FONT SIZE=3D3 PTSIZE=3D12 FAMILY=
=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">In reviewing my code for the long dou=
ble functions, I've referred<BR>
to specifications in both C99 [ISO/IEC 9899:1999 (E)] and Posix,<BR>
at <A HREF=3D"http://www.opengroup.org/onlinepubs/007904975/">http://www.ope=
ngroup.org/onlinepubs/007904975/</A>. There are<BR>
wide discrepancies in these documents for the llrint functions.<BR>
<BR>
Paragraph 7.12.9.5 of ISO/IEC 9899:1999 (E) states:<BR>
<BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">&=
gt;<BR>
> The lrint and llrint functions round their argument to the<BR>
> nearest integer value, rounding according to the current<BR>
> rounding direction. If the rounded value is outside the<BR>
> range of the return type, the numeric result is unspecified.<BR>
> A range error may occur if the magnitude of x is too large.<BR>
> <BR>
<BR>
Further, in paragraph F.9.6.5 is the following:<BR>
<BR>
> <BR>
> The lrint and llrint functions provide floating-to-integer <BR>
> conversion as prescribed by IEC 60559. They round according <BR>
> to the current rounding direction. If the rounded value is <BR>
> outside the range of the return type, the numeric result is <BR>
> unspecified and the invalid exception is raised. When they <BR>
> raise no other exception and the result differs from the <BR>
> argument, they raise the inexact exception.<BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D3 PTSIZE=3D12 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><=
BR>
<BR>
In the Posix document for llrint, llrintf, and llrintl are the <BR>
following specifications:<BR>
<BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">&=
gt; These functions shall round their argument to the nearest <BR>
> integer value, rounding according to the current rounding <BR>
> direction.<BR>
> <BR>
> An application wishing to check for error situations should <BR>
> set errno to zero and call feclearexcept(FE_ALL_EXCEPT) before <BR>
> calling these functions. On return, if errno is non-zero or <BR>
> fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW) <B=
R>
> is non-zero, an error has occurred.<BR>
> <BR>
> RETURN VALUE<BR>
> Upon successful completion, these functions shall return the <BR>
> rounded integer value.<BR>
> <BR>
> If x is NaN, a domain error shall occur, and an unspecified value is re=
turned.<BR>
> If x is +Inf, a domain error shall occur and an unspecified value is re=
turned.<BR>
> If x is -Inf, a domain error shall occur and an unspecified value is re=
turned.<BR>
> If the correct value is positive and too large to represent as a long l=
ong, <BR>
> a domain error shall occur and an unspecified value is returned.<BR>
> <BR>
> If the correct value is negative and too large to represent as a long l=
ong, <BR>
> a domain error shall occur and an unspecified value is returned. <BR>
> <BR>
> ERRORS<BR>
> These functions shall fail if:<BR>
> <BR>
> Domain Error <BR>
> The x argument is NaN or =B1Inf, or the correct value is not representa=
ble <BR>
> as an integer. If the integer expression (math_errhandling & MATH_E=
RRNO) <BR>
> is non-zero, then errno shall be set to [EDOM]. If the integer expressi=
on <BR>
> (math_errhandling & MATH_ERREXCEPT) is non-zero, the invalid floati=
ng-point <BR>
> exception shall be raised. <BR>
> <BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D3 PTSIZE=3D12 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><=
BR>
So, C99 says return a range error if the rounded result is too large,<BR>
whereas Posix requires a domain error regardless of the kind of error.<BR>
<BR>
Which way is the right way? The code, written a couple of years ago, <=
BR>
proceeds as follows:<BR>
<BR>
If the argument is a NaN, set domain error [EDOM]. If the rounded <BR>
result is too large (including +- Inf), set range error [ERANGE].<BR>
In both cases, the invalid floating-point exception is raised.<BR>
<BR>
<BR>
KB Williams</FONT></HTML>
--part1_5f.43e4a8d9.2d356a0e_boundary--
- Raw text -