Email List: Xaustin-group-lX
[All Lists]

Re: The C99 TC2 maths aardvarks

To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: The C99 TC2 maths aardvarks
From: Geoff Clare <yyy@xxxxxxxxxxxxx>
Date: Tue, 2 Aug 2005 17:07:05 +0100
References: <20050720160935.GA16831@squonk.masqnet>
As requested in the minutes of the July 28 teleconference, here
is an updated version of my notes on the C99 TC2 maths aardvarks.

Geoff.

------------

Note that the C Standard uses "range error" to refer to both overflow
and pole errors (it only distinguishes between them in Annex F where
it says which exception is raised).  I have used "pole error" instead
where appropriate.

Fred Tydeman raised a separate issue, not related to C99 TC2, about
the C Standard's requirement for underflow errors on MX systems.
I have indicated what additional changes would be needed if the
group wants to handle this issue in these aardvarks for the
functions they relate to.  (A separate aardvark would still need
to be raised for other affected functions.)

XSH ERN 69 fma

    ISO C TC2 #57 adds a "may" range error for non-MX systems.
    The Annex F requirements (for MX systems) are unchanged.

    After line 12499 add a new paragraph:

        If the result overflows or underflows, a range error may
        occur. [MX] On systems that support the MX option, if the
        result overflows a range error shall occur.[/MX]

    [Underflow issue: "overflows" -> "overflows or underflows" in last
    line of added text.]

    Remove the MX shading from lines 12527-12531 (the "may fail"
    underflow range error), and add an unshaded overflow range error
    to the "may fail" block.

    [Underflow issue: also add an MX shaded underflow range error to
    the "shall fail" block.]

XSH ERN 71 ilogb

    Although this one has been closed, I have noticed a couple of
    minor problems with the resolution.  One is that detailed changes
    to the RETURN VALUE section are only given for the "x is zero"
    case - the significance of the "and subsequent lines" part of the
    editing instructions could easily be missed when they are applied
    (or it could be applied to too many lines).  The other is that,
    since ISO C TC2 allows either a domain error or a range error for
    these cases but we are only allowing a domain error, should we not
    CX shade a suitable part of the text?

    The following is a proposed updated resolution.

    Replace line 20039 with:

        If x is 0, the value FP_ILOGB0 shall be returned.
        [XSI] On XSI-conformant systems a domain error shall
        occur,[/XSI] otherwise a
        [CX] domain [/CX] error may occur.

    Replace line 20040 with:

        If x is ħInf, the value INT_MAX shall be returned.
        [XSI] On XSI-conformant systems a domain error shall
        occur,[/XSI] otherwise a
        [CX] domain [/CX] error may occur.

    Replace line 20041 with:

        If x is a NaN, the value FP_ILOGBNAN shall be returned.
        [XSI] On XSI-conformant systems a domain error shall
        occur,[/XSI] otherwise a
        [CX] domain [/CX] error may occur.

    In the ERRORS section, add a "may fail" block, with an unshaded
    domain error for the "zero, NaN, or ħInf" cases.

XSH ERN 72 and 73 ilogb

    ISO C TC2 #49 adds a statement that an unspecified value is
    returned if the correct value is outside the range of the return
    type.  POSIX/SUS requires specific return values for XSI systems,
    but we ought to add the new statement for non-XSI systems.

    ISO C TC2 #79 makes the same addition in the Annex F requirements
    (for MX systems) but also adds a requirement that the "invalid"
    floating-point exception is raised.  We already require this (via
    the domain error description) for XSI systems but need to extend
    the requirement to (non-XSI) MX systems.

    Replace lines 20042-20045 with:

        If the correct value is greater than INT_MAX, [MX] a domain
        error shall occur and [/MX] an unspecified value shall be
        returned.
        [XSI] On XSI-conformant systems, a domain error shall occur
        and INT_MAX shall be returned.[/XSI]

        If the correct value is less than INT_MIN, [MX] a domain
        error shall occur and [/MX] an unspecified value shall be
        returned.
        [XSI] On XSI-conformant systems, a domain error shall occur
        and INT_MIN shall be returned.[/XSI]

    In the ERRORS section, the description of the "shall fail" domain
    error needs to be split in two, so that the "correct value not
    representable" part is shaded MX|XSI and the "zero, NaN, or ħInf"
    part is shaded XSI.

XSH ERN 74 llrint

    ISO C TC2 #53 relaxes the requirements for non-MX systems for
    the "outside the range of the return type" case from a "may"
    range error to a "may" domain or range error.  The Annex F
    requirements (for MX systems) are unchanged.

    Replace lines 23266-23269 with:

        If the correct value is positive and too large to represent
        as a long long, an unspecified value shall be returned.
        [MX] On systems that support the MX option, a domain error
        shall occur,[/MX] otherwise a
        [CX] domain [/CX] error may occur.

        If the correct value is negative and too large to represent
        as a long long, an unspecified value shall be returned.
        [MX] On systems that support the MX option, a domain error
        shall occur,[/MX] otherwise a
        [CX] domain [/CX] error may occur.

    In the ERRORS section add a "may fail" block with an unshaded
    domain error for the "correct value is not representable as an
    integer" case.

XSH ERN 75 llround

    ISO C TC2 #54 relaxes the requirements for non-MX systems for
    the "outside the range of the return type" case from a "may"
    range error to a "may" domain or range error.  The Annex F
    requirements (for MX systems) are unchanged.

    Replace lines 23318-23321 with:

        If the correct value is positive and too large to represent
        as a long long, an unspecified value shall be returned.
        [MX] On systems that support the MX option, a domain error
        shall occur,[/MX] otherwise a
        [CX] domain [/CX] error may occur.

        If the correct value is negative and too large to represent
        as a long long, an unspecified value shall be returned.
        [MX] On systems that support the MX option, a domain error
        shall occur,[/MX] otherwise a
        [CX] domain [/CX] error may occur.

    In the ERRORS section add a "may fail" block with an unshaded
    domain error for the "correct value is not representable as an
    integer" case.

XSH ERN 76 logb

    ISO C TC2 #50 relaxes the requirements for non-MX systems for
    the "argument is zero" case from a "may" domain error to a
    "may" domain or range error.  The Annex F requirements (for
    MX systems) are unchanged.

    Replace lines 24027-24028 with:

        If x is 0, logb(), logbf(), and logbl() shall return
        -HUGE_VAL, -HUGE_VALF, and -HUGE_VALL, respectively.
        [MX] On systems that support the MX option a pole error
        shall occur,[/MX] otherwise a
        [CX] pole [/CX] error may occur.

    In the ERRORS section add MX shading to the "shall fail" pole
    error, and add a "may fail" block with an unshaded pole error for
    the "x is 0" case.

XSH ERN 77 lrint

    The changes needed are equivalent to those specified for llrint()
    in XSH ERN 74 (but with "long long" changed to "long").

XSH ERN 78 lround

    The changes needed are equivalent to those specified for llround()
    in XSH ERN 75 (but with "long long" changed to "long").

XSH ERN 79 nexttoward

    ISO C TC2 #80 has no impact on POSIX/SUS.
    (Since no change is needed, the aardvark should be marked Reject.)

XSH ERN 81 pow

    ISO C TC2 #51 relaxes the requirements for non-MX systems for
    the "x is zero and y is less than zero" case(s) from a "may" domain
    error to a "may" domain or range error.  The Annex F requirements
    (for MX systems) are unchanged.

    Replace lines 31424-31427 with:

        For y < 0, if x is zero, a [CX] pole [/CX] error may occur and
        pow(), powf(), and powl() shall return ħHUGE_VAL, ħHUGE_VALF,
        and ħHUGE_VALL, respectively.
        [MX] On systems that support the MX option a pole error shall
        occur and pow(), powf(), and powl() shall return ħHUGE_VAL,
        ħHUGE_VALF, and ħHUGE_VALL, respectively if y is an odd
        integer, or HUGE_VAL, HUGE_VALF, and HUGE_VALL, respectively
        if y is not an odd integer.[/MX]

    (These lines could also be moved to after 31407 if desired.)

    [Underflow issue: lines 31406-31407 need to be changed to say
    the underflow range error "shall occur" on MX systems.]

    In the ERRORS section add a "may fail" block with an unshaded pole
    error for the "x is zero and y is negative" case.

    [Underflow issue: also add an MX shaded underflow range error to
    the "shall fail" block.]

XSH ERN 82 remainder

    ISO C TC2 #55 clarifies the allowed behaviour(s) for non-MX systems
    when y is zero.  The Annex F requirements (for MX systems) are
    unchanged.

    Insert a new paragraph after line 38475:

        On systems that do not support the MX option, if y is zero it
        is implementation-defined whether a domain error occurs or
        zero is returned.

    In the ERRORS section add a "may fail" block with an unshaded
    domain error for the "y is zero" case.

XSH ERN 83 remquo

    ISO C TC2 #56 does the same for remquo() as #55 does for remainder()
    but also adds a statement about the value of *quo being unspecified
    when y is zero.

    The changes needed are equivalent to those specified for remainder()
    in XSH ERN 82, plus an additional change:

    Append to line 38578:

        "If y is zero, the value stored in the object pointed to by
        quo is unspecified."

XSH ERN 85 tgamma

    ISO C TC2 #52 relaxes the requirements for non-MX systems for
    the negative integer and zero cases from a "shall" domain error
    to a "may" domain or range error.  The Annex F requirements
    (for MX systems) are unchanged.

    Replace lines 47772-47773 with:

        If x is a negative integer, a [CX] domain [/CX] error may
        occur and either a NaN (if supported) or an
        implementation-defined value shall be returned.
        [MX] On systems that support the MX option a domain error
        shall occur and a NaN shall be returned.[/MX]

        If x is zero, tgamma(), tgammaf(), and tgammal() shall
        return ħHUGE_VAL, ħHUGE_VALF, and ħHUGE_VALL, respectively.
        [MX] On systems that support the MX option a pole error shall
        occur,[/MX] otherwise a
        [CX] pole [/CX] error may occur.

    Delete lines 47779-47780.

    In the ERRORS section add a "may fail" block with an unshaded
    domain error for the "x is a negative integer" case and an
    unshaded pole error for the "x is zero" case.  Extend the MX
    shading to the whole of the "shall fail" domain error.

-- 
Geoff Clare <yyyyyyy@xxxxxxxxxxxxx>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England

<Prev in Thread] Current Thread [Next in Thread>