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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1911 Actions

    Problem Report Number 1911
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0230
    Raised 2002-06-04 08:00
    Updated 2003-03-13 08:00
    Published 2002-06-11 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.6
    Test Identification LFS.os/ioprim/fcntl 4
    Specification System Interfaces and Headers Issue 5
    Location in Spec See Problem Text
    Linked Problem Reports PIN5.003, (in, old, system)
    Problem Summary PIN5.010 The consultants stated in PG5R.010 The basis for granting PIN5.003 was the description of the EINVAL error for lseek() in POSIX.1-1996: [EINVAL] ... the resulting file offset would be invalid and a de...
    Problem Text
    The consultants stated in PG5R.010

    The basis for granting PIN5.003 was the description of the EINVAL
    error for lseek() in POSIX.1-1996:

    [EINVAL] ... the resulting file offset would be invalid

    and a decision by the Base Working Group that it is acceptable for
    implementations to treat the offset used in the lseek() call made
    by VSX5.1.4 as invalid.

    Now that the test has been modified to avoid using an invalid offset in
    the lseek() call, the test fails at the subsequent fcntl() call. The
    question now is whether the specification allows fcntl() to set errno
    to EINVAL instead of EOVERFLOW under the conditions set up by the test.

    The only relevant part of the description of the EINVAL error for
    fcntl() in XSH5 is:

    [EINVAL] ... the cmd argument is F_GETLK, F_SETLK or F_SETLKW and
    the data pointed to by arg is not valid

    This condition would apply to the test if the struct flock used in the
    fcntl() call contains some invalid data. The values set in struct flock
    are as follows:

    l_type is F_WRLCK
    l_whence is SEEK_CUR
    l_start is set to the maximum value of off_t
    l_len is 0

    None of these values is invalid, and so the condition does not apply.

    Implementor response:

    The value l_start is invalid, PIN5.003 allowed that there need be no
    relationship between maximum value of off_t and allowed maximum filesize
    on an implementation's file system.

    Granted that PIN5.003 dealt with behavior of lseek() not fcntl(), the
    argument(which is a granted grey area in SUSV2) made with respect to
    maximum file size versus maximum off_t value still apply: from PIN5.003
    (reworded to discuss fcntl()).

    ----------------------------------------------------------------------------
    XBD5 on page 21 states that "offset maximum" is the largest value that can
    be used as a file offset.

    "can be used as a file offset" does not guarantee sucessful use, as an off_t
    may be of one size but filesystem maximums may prevent actual use of certain
    ranges.

    Submitter disagrees that the fcntl() and associated failures that come from
    the current testing mechanism are improper:

    1) fcntl() must return EINVAL if the "cmd argument is F_GETLK, F_SETLK or
    F_SETLKW and the data pointed to by arg is not valid".
    2) It is possible for a file offset to be invalid even if the value *is*
    *less* than the offset maximum. There is no specification requirement that
    the maximum allowable offset must also be the allowable maximum filesize,
    and thus making certain ranges invalid on smaller filesystems with large
    off_t types.
    3) Thus, it may not be possible to portably test for EOVERFLOW, or even
    test for it at all, as a UNIX conforming system is not required to have
    maximum filesizes equal to the maximum value storable in an off_t.
    a claim can be made that EOVERFLOW is detectable for read() in a 32-bit
    application (and thus the CSQ answers "yes"), but the detection will never
    happen in the 64-bit version of the same application running on the same
    system, given maximum filesizes smaller than 2**63 (regardless of
    off_t size).

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

    The recoding of the test just moved the location of the failure, but it fails
    for the same reason.
    Test Output
    ************************************************************************
    /tset/LFS.os/ioprim/fcntl/T.fcntl 4 Failed

    Test Description:
    When cmd is F_GETLK, FSETLK or F_SETLKW and l_len is zero and the
    smallest offset in the requested segment cannot be represented in an
    entity of type off_t, then a call to fcntl() returns -1 and sets errno
    to EOVERFLOW.

    Test Strategy:
    OBTAIN limit-setting privilege, using setprv(PRV_LIMITS)
    SET the hard and soft file size limits to RLIM_INFINITY, using
    setrlimit()
    OPEN a new file in the current directory, using creat()
    REPEAT for F_GETLK, F_SETLK and F_SETLKW:
    SEEK to offset 1, using lseek()
    CALL fcntl() with l_type=F_WRLCK, l_whence=SEEK_CUR,
    l_start=LFS_NORMAL_OFFMAX, l_len=0
    VERIFY that fcntl() returned -1 with errno set to EOVERFLOW

    Test Information:
    fcntl(F_GETLK) set errno to 22 (EINVAL), expected 127 (EOVERFLOW)
    fcntl(F_SETLK) set errno to 22 (EINVAL), expected 127 (EOVERFLOW)
    fcntl(F_SETLKW) set errno to 22 (EINVAL), expected 127 (EOVERFLOW)

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

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The reason I did not consider that the lseek() grey area should apply
    to the l_start value passed to fcntl() was because of a difference in
    wording in the EINVAL errors for lseek() and fcntl().

    For lseek() the wording is "the resulting file offset would be invalid".
    For fcntl() it is "the data pointed to by arg is not valid". The
    difference is that for lseek() the error condition refers to the
    resulting file offset, not the off_t value passed to lseek(), whereas
    for fcntl() the error condition refers to the contents of the struct
    flock (and thus to the off_t value in l_start), not to the resulting
    start offset of the lock.

    However, on re-examining the description of fcntl() I have noticed the
    following text relating to l_start and l_len:

    "A lock will be set to extend to the largest possible value of the
    file offset for that file by setting l_len to 0."

    Since the requested starting offset in the test is already beyond the
    "largest possible value of the file offset" for the file on this
    implementation (as allowed by PIN5.003), I now believe that the
    lseek() grey area does have relevance to the lock offsets in fcntl()
    calls, and that an EINVAL error from fcntl() is an acceptable
    behaviour under the conditions set up by this test.

    It is recommended that a permanent interpretation is granted.

    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