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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0400 Actions

    Problem Report Number 0400
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0019
    Raised 1992-10-13 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.2.4
    Test Identification POSIX.os/ioprim/fcntl,lockf
    Problem Summary PG4R.019 The data type off_t defines the data type used for file length and file offset. Normally the maximum value for off_t will be the maximal positive number of the underlying basic arithmetic data type. T...
    Problem Text
    The data type off_t defines the data type used for file length
    and file offset. Normally the maximum value for off_t will be the maximal
    positive number of the underlying basic arithmetic data type.
    Thus the number FCHR_MAX+1 will be a negative value and therefore invalid.
    The theoretically maximal possible offset into a file will be (maximal file
    length -1) which is equal to FCHR_MAX-1. For fcntl() locking usage a lock
    region can expand over actual file sizes.
    The question is whether fcntl() locking calls have to respect such a
    restriction.
    Additionally there is the question whether such a not XPG3 documented
    constant -- which can (and did already) cause incompatibilities and possible
    porting problems -- has to be obeyed.

    ---------------------------------------
    Further Information from the Originator
    ---------------------------------------

    In some SVR4 systems a constant FCHR_MAX has to be respected when
    using fcntl() or lseek() system calls.
    If it does not respect the constant, the caller will get an error
    return EINVAL in certain cases.

    The data type off_t defines the data type used for file length
    and file offset. Therefore the maximum value for off_t will be the maximal
    positive number of the underlying basic arithmetic data type.

    This limit can be defined as a constant FCHR_MAX.
    Thus the number FCHR_MAX+1 will be a negative value and therefore invalid.
    The theoretically maximal possible offset into a file will be (maximal file
    length -1) which is equal to FCHR_MAX-1. This would impose additional
    semantics on fcntl() and lseek() calls.
    For fcntl() locking usage a lock region can expand over actual file sizes.

    The limit FCHR_MAX is not documented by POSIX.1, XPG or SVID and as such
    can only be considered to be an extension to these standards. The SVID
    mentions this limit in relation to the RLIMIT_FSIZE resource limit and
    states that the FCHR_MAX implementation defined constant is affected by
    the setting of this resource limit. The RLIMIT_FSIZE limit is refered to
    as the "maximum size of a file in bytes that can be created by a process".
    Assuming that FCHR_MAX is related to this limit, it is to be inferred that
    FCHR_MAX is the default for this maximum.

    Since fcntl() and lseek() are both able to address offsets beyond the
    length of the file, it is unnecessary for the implementation to impose
    the FCHR_MAX limit to these calls. The only implication that XPG 4 gives is
    that the value returned by lseek() must be representable in the type off_t
    and that the l_start and l_len members of the lock structure returned from
    a call to fcntl() with the command F_GETLK should be representable in the
    type off_t. The implication is that any attempt to seek to a position or
    to set a lock containing a position that transgresses these rules should
    result in an EINVAL error. (Note that this is not explicitly stated in the
    XPG and this implication is based on the assumption that the system will
    behave in a consistent manner. Also note that the implications for fcntl()
    are based on the requirement that the lock structure information is
    provided relative to SEEK_SET).

    There is no strong argument for allowing a behaviour that imposes an
    error return EINVAL for fcntl() and lseek() calls in case that restrictions
    based on a constant FCHR_MAX (other than obeying to the basic data type rules)
    are hurt.
    Test Output
    In some SVR4 systems a constant FCHR_MAX has to be respected when
    calling fcntl() or lseek() system calls.
    If she does not respect the constant the caller will get an error
    return EINVAL in certain cases.

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The limit FCHR_MAX is not documented by POSIX.1, XPG or SVID and as such
    can only be considered to be an extension to these standards. The SVID
    mentions this limit in relation to the RLIMIT_FSIZE resource limit and
    states that the FCHR_MAX implementation defined constant is affected by
    the setting of this resource limit. The RLIMIT_FSIZE limit is refered to
    as the "maximum size of a file in bytes that can be created by a process".
    Assuming that FCHR_MAX is related to this limit, it is to be inferred that
    FCHR_MAX is the default for this maximum.

    Since fcntl() and lseek() are both able to address offsets beyond the length
    of the file, it seems unnecessary for the implementation to impose the
    FCHR_MAX limit to these calls. The only implication that XPG 4 gives is
    that the value returned by lseek() must be representable in the type off_t
    and that the l_start and l_len members of the lock structure returned from
    a call to fcntl() with the command F_GETLK should be representable in the
    type off_t. The implication is that any attempt to seek to a position or
    to set a lock containing a position that transgresses these rules should
    result in an EINVAL error. (Note that this is not explicitly stated in the
    XPG and this implication is based on the assumption that the system will
    behave in a consistent manner. Also note that the implications for fcntl()
    are based on the requirement that the lock structure information is provided
    relative to SEEK_SET).

    The request wishes to ascertain whether an XPG 4 system may, as an
    extension, indicate an EINVAL error for the fcntl() and lseek() calls in the
    case that an offset greater than FCHR_MAX is addressed. While I cannot see
    a strong argument for allowing this behaviour, I believe that this should be
    forwarded to the K/RT group for further consideration.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This waiver request is refused. The request has not been specific enough in
    detailing the behaviour of the system under test.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority