Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2460 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 2460.

Report 2460 Actions

    Problem Report Number 2460
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.1282
    Raised 2005-05-10 02:34
    Updated 2005-06-06 19:13
    Published 2005-06-06 19:13
    Product Standard Internationalised System Calls and Libraries Extended V3 (UNIX 03)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.6.4
    Test Identification ANSI.os/string/strerror_X/T.strerror_X 2
    Specification Base Definitions Issue 6
    Problem Summary strerror_X 2 does not allow for may fail EINVAL in UNIX03 mode
    Problem Text In UNIX03 mode, strerror_X 2 does not allow for a may fail EINVAL error.

    In all of the corresponding specs there is the may fail error condition:
    [EINVAL] The value of errnum is not a valid error number.

    When we get an invalid error number, we set errno to EINVAL and return a
    pointer to the string "Unknown error" (properly translated for the
    current locale). This exactly matches the behavior specified by the
    XSH4, XSH5, and XSH6. Since this EINVAL is a may fail rather than shall
    fail condition, implementations should be free to leave errno unchanged
    or to set errno to EINVAL in this condition and the test suite should
    allow either behavior.
    Test Output ****************************************************************************************************************
    /tset/ANSI.os/string/strerror_X/T.strerror_X 2 Failed

    Test Description:
    For XPG4 and UNIX98 modes:
    When the value of errnum is not a valid error number, then
    strerror(errnum) either sets errno to EINVAL or returns a
    pointer
    to a message string and does not change errno.
    For other test modes:
    When errnum has any value in the range INT_MIN to INT_MAX, then
    strerror(errnum) returns a pointer to a message string and does
    not change errno.

    Test Strategy:
    IF the test mode is XPG4 or UNIX98:
    SET errno to zero
    CALL strerror(-1)
    IF errno is zero:
    VERIFY that strerror() returned a pointer to a message
    string
    OTHERWISE:
    VERIFY that errno is equal to EINVAL
    OTHERWISE:
    FOR errnum values INT_MIN, -1, and INT_MAX:
    SET errno to zero
    CALL strerror(errnum)
    VERIFY that errno is zero
    VERIFY that strerror() returned a pointer to a message
    string

    Test Information:
    strerror(-2147483648) set errno to 22 (EINVAL)
    strerror(-1) set errno to 22 (EINVAL)
    strerror(2147483647) set errno to 22 (EINVAL)


    ****************************************************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date 2005-05-10 02:34
    Last Updated 2005-05-10 18:45
    Completed 2005-05-10 18:45
    Status Complete
    Review Recommendation No Resolution Given
    Review Response The XSH6 specification is confusing as regards the behaviour of
    strerror() with arguments that are not valid error numbers.

    In the DESCRIPTION section it says "The strerror() function shall map
    the error number in errnum to a locale-dependent error message string
    and shall return a pointer to it. Typically, the values for errnum
    come from errno, but strerror() shall map any value of type int to a
    message." Then in the RETURN VALUE section it says "Upon successful
    completion, strerror() shall return a pointer to the generated message
    string." The former of these two quotes requires that a message
    string is returned for all argument values. The latter implies that
    generation of a message string means the call was successful.
    Combining the two means that an error can never occur, in which case
    the inclusion of the text "On error errno may be set, but no return
    value is reserved to indicate an error" is spurious.

    The DESCRIPTION section also says "The strerror() function shall not
    change the setting of errno if successful", which is why the test
    checks that errno has not changed.

    The specification needs to be clarified and therefore this request
    should be forwarded for expert group review. Two suggested ways to
    alter the specification are:

    1. Remove all of the following pieces of text:

    "The strerror() function shall not change the setting of errno
    if successful. Since no return value is reserved to indicate
    an error, an application wishing to check for error situations
    should set errno to 0, then call strerror(), then check errno."

    "On error errno may be set, but no return value is reserved to
    indicate an error."

    "These functions may fail if:"

    Change "Upon successful completion, strerror() shall return ..."
    to "The strerror() function shall return ..."

    Move the EINVAL error description to below "The strerror_r()
    function may fail if:".

    2. Change "Upon successful completion ..." to "Upon completion, whether
    successful or not, ..."

    Option 1 would make the requirements regarding errno the same as
    in the C Standard (i.e. the general rule about functions being
    allowed to set errno to a non-zero value on successful calls would
    apply).

    Option 2 would remove the implication that returning a message
    string means the call was successful. There would still be some
    confusion as to what it means for strerror() to "fail" (since it
    always returns a message), but at least the confusion over whether
    errno can be set would be gone.

    (Note that a third option which removes the requirement to generate a
    message when errnum is not a valid error number would not be a
    valid change to the specification as it would conflict with the
    C Standard.)

    Review Type SA Review
    Start Date 2005-05-10 17:45
    Last Updated 2005-05-12 00:37
    Completed 2005-05-12 00:37
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion This PR should be forwarded to the expert group for review.

    Review Type Expert Group Review
    Start Date 2005-05-12 20:33
    Last Updated 2005-06-06 19:12
    Completed 2005-06-06 19:12
    Status Complete
    Review Resolution Test Suite Deficiency (TSD)
    Review Conclusion The Base Working Group recommends a test suite deficiency. A
    conforming implementation may return a string such as "strerror failure" and
    set errno to EINVAL. Since there is no defined value for an error
    return, an application must set errno to zero before the call to
    strerror, and test it again afterwards, as specified on 44893-44894.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority