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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2477 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 2477.

Report 2477 Actions

    Problem Report Number 2477
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0272
    Raised 2005-09-14 08:26
    Updated 2006-02-17 03:01
    Published 2006-02-17 03:01
    Product Standard Internationalised System Calls and Libraries (XPG4)
    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 System Interface Definitions Issue 4
    Location in Spec strerror
    Problem Summary strerror() should not require a string of non-zero length if an invalid
    errnum is passed to the function
    Problem Text The standard is clear that strerror() returns a pointer to a string.
    The actual content of the string is not defined by the standard beyond
    stating that it will be mapped from the error number to a locale dependant
    message string.

    The standard is clear that an error may be detected by the function.
    The most recent version of the standard was altered to clarify that a
    pointer to a string is always returned, even if an error is detected.
    The only documented error that "may" be detected occurs if the application
    passes an invalid error number to the function.

    The verification suite is testing that the strerror() function returns a
    specific string content when the test calls the function with an invalid
    error number. The specific content is: The string must contain at least
    one byte of irrelevant value.

    Since the standard does not define any specific content for the returned
    string in the event of an error, the test is checking for a value that
    is outside the scope of the standard.

    Further Information from Submitter
    **********************************
    The strerror test <strerror_X #2> that asserts a pointer to null string
    is not
    a legitimate return value is making an assertion that is not defined by
    the UNIX standard.

    The Open Group consultant argued:

    This implementation has left errno unchanged but returned an empty
    string

    The ISO/IEC 9899:1990 (ISO-C standard) states

    7.11.6.2 The strerror function

    The strerror function maps the error number in errnum to an
    error message string.

    The strerror function returns a pointer to the string, the
    contents of which are implementation-defined.

    The ISO/IEC 9899:1999 (ISO-C standard) states

    7.21.6.2 The strerror function


    The strerror function maps the number in errnum to a message string.
    Typically, the values for errnum come from errno, but strerror shall
    map any value of type int to a message.

    The strerror function returns a pointer to the string, the
    contents of which are localespecific."

    Argument-1:

    C90 required that the function return a pointer to an implementation
    defined string. It was silent about what to do if the errnum was
    outside the domain of implementation supported error number values.

    C99 added the requirement that the function will map all values of
    errnum to a message string and the message string will be locale
    specific. Since the content of the message string is not defined by
    the standard, it remains implementation-defined.

    As long as an implementation of strerror returns a pointer to a string,
    and the string is locale specific, the content of the string is
    irrelevant to conformance.

    If an implementation documents that the strerror function returns a
    pointer to an empty string whenever the value of errnum is outside the
    domain of legitimate error numbers, then it has met the C90 criteria
    that the string is implementation-defined. If the translation of an empty
    string is unambiguous regardless of the locale, then it has met the C99
    criteria that the string is "localespecific".

    Argument-2:

    The IEEE Std 1003.1 states:

    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.


    Upon successful completion, strerror( ) shall return a pointer to
    the generated message string. On error errno may be set, but no
    return value is reserved to indicate an error.


    [This function] may fail if:
    [EINVAL] The value of errnum is not a valid error number.


    This text refines the C90/C99 definition but does not require any
    behavior beyond that defined for C90/C99.

    The consultant has argued:

    I don't believe that an empty string qualifies as "a message
    string", since it does not contain a message.

    Since our implementation documents the meaning of the empty string when
    it is returned by strerror( ), the empty string has meaning and
    qualifies as a message.

    Argument-3:

    The actual content of the string is not explicitly defined by C, POSIX
    or UNIX. A string that contains a single space " ", which is no more
    informative than an empty string "", would pass the conformance test.

    The content ofthe string is implementation defined and cannot be
    tested/parsed/understood by a conforming application, so the actual
    content plays no part in application portability.

    Thus, if a pointer to a string is returned, and the contents of the
    string are considered inadequate, it is a quality-of-implementation
    problem, not a UNIX conformance problem.
    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(-1) returned empty string

    Review Information

    Review Type TSMA Review
    Start Date 2005-09-14 08:26
    Last Updated 2005-09-14 18:07
    Completed 2005-09-14 18:07
    Status Complete
    Review Recommendation Permanent Interpretation (PIN)
    Review Response The XSH4 specification states "The strerror() function maps the error
    number in errnum to a locale-dependent error message string and returns
    a pointer thereto". It also states "On error errno may be set, but no
    return value is reserved to indicate an error", and "The strerror()
    function may fail if: [EINVAL] The value of errnum is not a valid error
    message number".

    Since the error is optional there are two allowed behaviours for
    strerror(-1):

    1. It sets errno to EINVAL (or to another non-zero value if a different
    error condition also occurs) and returns any value, or

    2. It leaves errno unchanged and returns a pointer to an error message
    string.

    This implementation has left errno unchanged but returned an empty
    string. An empty string does not qualify as an "error message string"
    because it does not contain an error message.

    In order to comply with the specification the implementation needs to be
    changed so that strerror(-1) either sets errno to EINVAL or returns an
    error message (i.e. non-empty) string.

    Further Response from TSMA
    **************************
    In Argument-1 the consultant agrees that the implementation's strerror()
    function conforms to the requirements of C90. However, the test is
    related to additional requirements made by SUSv1 (the optional EINVAL
    error condition), and so conformance to C90 does not have any bearing
    on the issue. The discussion of C99 is irrelevant since SUSv1
    references C90, not C99.

    In Argument-2 the submitter quotes some text from POSIX.1-2001.
    Although this version of POSIX is not relevant (because SUSv1
    references POSIX.1-1990 which does not require strerror()), the
    quoted text is approximately the same as the text from SUSv1 and so is
    relevant. It is the part at the end of Argument-2 that is the crux of
    the matter - the question of whether an empty string qualifies as an
    "error message string" (or even as just a "message string"). The
    consultant's opinion is still that an empty string is neither of
    these things, since it does not contain a meaningful message.

    In Argument-3 it is true that a string containing a single space
    would pass the test. The reason for this is, as the submitter
    points out, that a message string returned by strerror() cannot
    be parsed or understood by the test program. It could be considered
    that the test produces false passes when a non-empty string is
    returned that can be determined to contain no meaningful message,
    such as a single space. An empty string is a special case that can
    easily be tested for, and that is why the test covers only this
    type of non-message-containing string and not others.
    It could also be argued that a single space can convey a meaningful
    message - for example all error messages could consist of a single
    byte and the system could be supplied with documentation which
    explains their meanings. Either way, the argument is not relevant
    to the issue. (If a single space is not an "error message string"
    then an empty string is also not an "error message string" and the
    test produces false passes for the single space case but is still
    right to fail an empty string; if a single space is an "error message
    string" then the test is right to report a pass for this case and
    the situation for an empty string is determined only by Argument-2.

    Review Type SA Review
    Start Date 2005-09-14 17:07
    Last Updated 2005-09-15 02:41
    Completed 2005-09-15 02:41
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion The SA originally rejected this PR as a TSD.

    The submitter decided to appeal this ruling and challenge that the
    wording in the standard is ambiguous with respect to its intent by
    applying for an
    interpretation, or indeed may appeal this ruling and requesting a 14 day
    review by the Base Working Group.

    Expert Group response.

    The standard permits this behavior. It is recommended
    that a permanent interpretation be granted.

    Despite argument #2 in the further response from TSMA, with no
    definition of the terms "message string" and "error message string", we
    believe we have to fall back to the basic definition in C of "string".
    Furthermore, in this specific case of mapping an invalid error number
    into an error message string, we don't see any normative requirement
    saying that translating a number that is not an valid error number into
    an empty string is wrong. The standard does not clearly require that
    the generated error message string produced by strerror(),
    strerror_r(), perror() not be an empty string (even for valid errno
    values).

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority