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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1906 Actions

    Problem Report Number 1906
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0225
    Raised 1998-05-13 08:00
    Updated 2003-03-13 08:00
    Published 1998-06-08 08:00
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSX5 version 5.1.4
    Test Identification LFS.os/ioprim/lseek 2
    Specification System Interfaces and Headers Issue 5
    Location in Spec See Problem Text
    Problem Summary PIN5.005 Each of tests fail in the 64-bit test environment where the tests are built as a 64-application. Though these tests are in the Large Files section of the test suite, the Large File compilation options...
    Problem Text
    Each of tests fail in the 64-bit test environment where the tests
    are built as a 64-application. Though these tests are in the Large
    Files section of the test suite, the Large File compilation options
    are not used to build them since by default, applications built as
    64-bit on our implementation are large file aware.

    Each of these tests fail for the same reason though the results for
    fseek indicate a SIGSEGV due to an error in the test suite. This
    SIGSEGV error is addressed in another waiver request.

    The following three test cases are attempting to create an error
    condition by attempting to seek one byte beyond the maximum offset:

    /tset/LFS.os/ioprim/lseek/T.lseek 2
    /tset/LFS.os/streamio/fseek/T.fseek 3
    /tset/LFS.os/streamio/fseeko/T.fseeko 17

    The expectation is that the function will return -1 and set errno to
    EOVERFLOW. Using the lseek test as an example, it seeks to LONG_MAX
    successfully and then attempts to lseek(0, 1L, SEEK_CUR) which yields
    an offset of LONG_MAX + 1 which is a negative value, and hence an
    invalid offset that cannot be represented correctly in an object of
    type off_t. We set errno to EINVAL in this environment and believe
    this is valid based on the following taken from the XSH5 specification:

    Reference page 489 for lseek():

    [EINVAL] The whence argument is not a proper value, or the
    resulting file offset would be invalid.

    [EOVERFLOW] The resulting file offset would be a value which cannot
    be represented correctly in an object of type off_t.

    Reference page 282 for fseek() and fseek():

    [EINVAL] The whence argument is not a proper value, or the
    resulting file offset would be set to a negative value.

    [EOVERFLOW] For fseek(), the resulting file offset would be a value
    which cannot be represented correctly in an object of
    type long.

    [EOVERFLOW] For fseek0(), the resulting file offset would be a
    value which cannot be represented correctly in an object
    of type off_t.

    Because in the environment under test, an attempt to go 1 byte beyond
    the maximum offset will result in a negative offset which is considered
    invalid, we believe we are correct in setting errno to EINVAL, though
    it also may be considered correct to set errno to EOVERFLOW. We feel
    the tests should allow for the possibility of either error condition
    in this case.
    Test Output

    /tset/LFS.os/ioprim/lseek/T.lseek 2 Failed
    Test Description:
    When the file position requested by a seek operation would be larger
    than the value that can be contained in an entity of type off_t, then
    a call to lseek() returns -1, sets errno to EOVERFLOW and the file
    pointer is unchanged.
    Test Strategy:
    LSEEK to LFS_NORMAL_OFFMAX
    VERIFY this succeeds
    ATTEMPT to lseek(0, 1L, SEEK_CUR)
    VERIFY that this returns -1 and sets errno to EOVERFLOW
    Test Information:
    lseek() failed to set errno correctly...
    got errno 22 (EINVAL), expected errno 79 (EOVERFLOW)


    /tset/LFS.os/streamio/fseek/T.fseek 3 Failed
    Test Description:
    When a call to fseek() attempts to set the file pointer to a position
    which cannot be represented in a value of type long, then the call
    returns -1 and sets errno to EOVERFLOW.
    Test Strategy:
    OPEN a file
    FSEEK to LONG_MAX position from SEEK_SET
    VERIFY that this returns zero (succeeds)
    FSEEK to one byte past LONG_MAX using SEEK_CUR
    VERIFY that fseek() returned -1 and set errno to EOVERFLOW
    REMOVE test file.
    Test Information:
    unexpected signal 11 (SIGSEGV) received


    /tset/LFS.os/streamio/fseeko/T.fseeko 17 Failed
    Test Description:
    When a call to fseeko() attempts to set the file pointer to a position
    which cannot be represented in a value of type off_t, then the call
    returns -1 and sets errno to EOVERFLOW.
    Test Strategy:
    OPEN a file
    FSEEKO to LONG_MAX position from SEEK_SET
    VERIFY that this returns zero (succeeds)
    FSEEKO to one byte past LONG_MAX using SEEK_CUR
    VERIFY that fseeko() returned -1 and set errno to EOVERFLOW
    REMOVE test file.
    Test Information:
    fseeko() set errno to 22 (EINVAL), expected 79 (EOVERFLOW)

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The submitter refers to "an offset of LONG_MAX + 1 which is a negative value".
    This is mathematically incorrect. An offset of LONG_MAX + 1 is a positive
    value that is too large to fit in a long. If the implementation actually
    performs this addition and assigns the result to a long then this may well
    result in a negative value, depending on how the system handles integer
    overflow. The fact that an overflow has occurred, but did not produce an
    EOVERFLOW error, demonstrates that the implementation has not checked for
    the EOVERFLOW condition as required by the specification.

    Whilst granting a TSD for the reason claimed in the submitter's rationale
    is not recommended, there is also the question of whether there is a grey
    area here, similar to the one identified in PIN5.003. The main
    difference is that in PIN5.003 the lseek() call is expected to succeed
    but fails with EINVAL, whereas here the lseek() call is expected to fail
    but sets errno to the wrong value. Section 2.3 of XSH5 contains the
    following two statements:

    1. "If more than one error occurs in processing a function call, any
    one of the possible errors may be returned, as the order of detection
    is undefined."

    2. "Implementations will not generate a different error number from
    the ones described here for error conditions described in this
    specification"

    When applying these to the question of whether EOVERFLOW and EINVAL are
    both acceptable in the situation where the requested offset is larger
    than the maximum value of off_t, it should be noted that EOVERFLOW is
    explicitly required for this condition, whereas the details of the
    conditions that cause EINVAL are implementation-specific. So perhaps
    statement 2 should take precedence over statement 1 in this case, and if
    so this waiver request should be refused. Alternatively, a waiver for a
    Minor System Fault could be granted.

    This is a matter that the base working group should decide.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    We recommend a Temporary Interpretation and that the request should
    be forwarded for a 14 day review by the Base Working Group on the
    grounds that a similar problem has been identified in PIN5.003. It
    would appear that this may be a grey area in the specification.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    An interpretation should be granted.

    The intent of adding EOVERFLOW to open(), lseek(), stat(), and lots
    of other interfaces was not to detect mathematical overflow; it was
    to cause failures in applications that used (or were expected to use)
    values that were larger in the kernel than could be represented in the
    types being used by the application. (If an application running on a
    system that has 32-bit UIDs stat()s a file on a network where the UID
    representing the owner of the file uses 48 bits, stat() will return
    EOVERFLOW because the st_uid field in the stat structure can't hold a
    48-bit UID; not because any arithmetic operation failed.)

    The intent was that the kernel return EOVERFLOW when a value known
    by the kernel could not be returned to the user in the space the user
    had allocated.

    If an application using a 32-bit off_t running on this kernel (with
    a 64-bit off_t) does an lseek() to 0x7fffffff and then then seeks to 1
    beyond that point; the result would be a legal offset (0x0000000080000000)
    in the kernel, but could not be returned to the application as a positive
    value in a 32-bit off_t. This was the intent of EOVERFLOW in the LFS
    specification. In this case, however, the submitter is describing a
    64-bit application (presumably running on an operating system supporting
    64-bit off_t's in the kernel). The test suite is doing an lseek() to
    0x7fffffffffffffff and then seeks to 1 beyond that point. I believe the
    intent here was that what always used to happen (undetected arithmetic
    overflow yielding a negative value with errno set to EINVAL) before
    LFS added the EOVERFLOW error. Alternatively, the kernel could detect
    the arithmetic overflow and return EOVERFLOW. This would be a case of
    two possible errors. As pointed out by the consultants, since either
    of these errors (EOVERFLOW or EINVAL) would be legal at this point,
    the test suite should accept either one.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority