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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1656 Actions

    Problem Report Number 1656
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Temporary Interpretation (TIN)
    Problem Resolution ID TIN.X.0071
    Raised 2000-08-25 08:00
    Updated 2003-03-13 08:00
    Published 2000-09-26 08:00
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSU version 5.1.1
    Test Identification CAPI.os/ioprim/writev 76,77
    Specification System Interfaces and Headers Issue 5
    Location in Spec See Problem Text
    Problem Summary TIN4U.00003 This IR claims that a SIGXFSZ is allowed when writev() writes past the offset maximum
    Problem Text

    Please submit to the Base Working group for a 14 day interpretation.

    This failure also exists in the same test in VSU 5.0.4.

    in PG4U.00175 the consultants state

    The question is whether it is valid for the test suite to assume
    that regular files created in a particular directory (e.g. the one
    specified by VSU_LFS_DIR) will either always have a maximum size that
    is at least 2^32 bytes or always have a maximum size that is less
    than 2^32 bytes. The answer can be determined from the required
    behaviour of a call to pathconf(VSU_LFS_DIR, _PC_FILESIZEBITS).
    Specifically, the note in the description of pathconf:

    "If path or fildes refers to a directory, the value returned
    applies to filenames within the directory."

    and the definition of FILESIZEBITS in <limits.h>:

    "Minimum number of bits needed to represent, as a signed integer
    value, the maximum size of a regular file allowed in the specified
    directory"

    clearly show that on a UNIX98-compliant system, the minimum number of
    bits needed to represent the maximum size of regular files in one
    particular directory must be the same for all of the files in that
    directory. Therefore the assumption by the test suite concerning
    VSU_LFS_DIR is valid, and the writev test failures are due to a
    non-compliance of the system.


    A regular file on a LFS enabled filesystem will be a file with a 64 bit off_t.
    And our FILESIZEBITS returns the correct value for this case. However programs
    compiled in IPL32_OFF32 cannot generate or correctly access LFS files. Table
    3-4 (Page 165) of the XCU clearly shows that an program compiled in IPL32_OFF32
    has an off_t of 32 bits. And that a 64 bit off_t is reguired to
    create/access/modify large files.

    The XSH open() syscall requirements(page 572) states the following:


    "The largest value that can be represented correctly in an object of type off_t
    will be established as the offset maximum in the open file description."

    This clearly states that the maximum file size is dependent on the off_t size.

    In addition, the XSH exec() requirements states the following:


    "For those file descriptors that remain open, all attributes of the open file
    description, including file locks remain unchanged."

    These two statement mean that an IPL_OFF32 program can only open a file with
    maximum size of 2^32 and passing this file descriptor to a OFFBIG or OFF64
    program will not change this maximum file size.
    Test Output
    ************************************************************************
    /tset/CAPI.os/ioprim/writev/T.writev 76 Unresolved

    Test Description:
    Base Conditional Deviance
    If the implementation allows creation of a file description with an
    offset maximum less than the largest size it supports for an off_t:
    EFBIG in errno and return -1 on a call to ssize_t writev(int fildes,
    const struct iovec *iov, int iovcnt) when the file is a regular file,
    nbyte is greater than zero, and the starting position is equal to the
    offset maximum established in the open file description associated
    with fildes.

    Test Information:
    PREP: Check for existence of programming environments
    PREP: Obtain off_t size in XBS5_ILP32_OFF32 environment
    PREP: Obtain off_t size in XBS5_ILP32_OFFBIG environment
    INFO: Execution environment for XBS5_LP64_OFF64 not supported
    INFO: Execution environment for XBS5_LPBIG_OFFBIG not supported
    TEST: Execute a program compiled in XBS5_ILP32_OFF32(32-bit off_t)
    environment that:
    opens a regular file
    execs a program compiled in XBS5_ILP32_OFFBIG(64-bit off_t)
    environment,
    passing it the open file descriptor
    this program:
    sets the offset equal to the value that can be
    represented in a 32-bit off_t,
    verifies writev returns -1 and sets errno to EFBIG
    ERROR: In 32-bit program: ERROR: Child terminated due to signal 25

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

    ************************************************************************
    /tset/CAPI.os/ioprim/writev/T.writev 77 Unresolved

    Test Description:
    Base Conditional Deviance
    If the implementation allows creation of a file description with an
    offset maximum less than the largest size it supports for an off_t:
    EFBIG in errno and return -1 on a call to ssize_t writev(int fildes,
    const struct iovec *iov, int iovcnt) when the file is a regular file,
    nbyte is greater than zero, and the starting position is greater than
    the offset maximum established in the open file description associated
    with fildes.

    Test Information:
    PREP: Check for existence of programming environments
    PREP: Obtain off_t size in XBS5_ILP32_OFF32 environment
    PREP: Obtain off_t size in XBS5_ILP32_OFFBIG environment
    INFO: Execution environment for XBS5_LP64_OFF64 not supported
    INFO: Execution environment for XBS5_LPBIG_OFFBIG not supported
    TEST: Execute a program compiled in XBS5_ILP32_OFF32(32-bit off_t)
    environment that:
    opens a regular file
    execs a program compiled in XBS5_ILP32_OFFBIG(64-bit off_t)
    environment,
    passing it the open file descriptor
    this program:
    sets the offset to a value greater than what can be
    represented in 32-bit off_t,
    verifies writev returns -1 and sets errno to EFBIG
    ERROR: In 32-bit program: ERROR: Child terminated due to signal 25

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

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The submitter is confusing two different concepts - "maximum file size"
    and "offset maximum". Everything said about the offset maximum is
    correct. However, this has no relevance to the issue of whether a
    compliant system can impose different maximum file sizes on two
    files in the same directory. The maximum file size (as indicated
    by pathconf(dir, _PC_FILESIZEBITS)) is a property of the files, and
    is entirely independent of the offset maximum, which is a property
    of open file descriptions. Given a file for which the FILESIZEBITS
    value is 64, if the file is opened in a program with a 32-bit off_t
    the offset maximum for the returned file descriptor is (2^31)-1, but
    if the same file is opened in a program with a 64-bit off_t the
    offset maximum for that returned file descriptor is (2^63)-1.

    Regarding the statement that "a 64 bit off_t is required to
    create/access/modify large files", there is some truth in this,
    but it is difficult to see how this relates to the test failures.
    In the tests, the ILP32_OFF32 program does not attempt to create,
    access or modify a large file, it creates an empty file and
    passes the open file descriptor down to a program with an off_t
    of 64 or more bits. It is the other program that then attempts
    to write to the file.

    The submitter requests a 14 day Base Working group review, however
    I suggest that he should be given the opportunity to change his
    mind, given that there is a fundamental flaw in his new rationale.
    If he wishes to proceed with the 14 day review, it would be helpful
    if a copy of PG4U.00175 is included in the mail sent to the working
    group, in order to provide some context for the parts quoted here.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The request is being sent for a 14 day review.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    Base WG response:

    There was no clear concensus on whether the specification is correct
    as is, i.e. no SIGXFSZ should be generated in this condition, or whether
    there is a grey area.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Temporary Interpretation (TIN)
    Review Conclusion
    A Temporary Interpretation is granted pending the next meeting of
    the Base WG (in Austin during Oct 10-13).

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority