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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 2019 Actions

    Problem Report Number 2019
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0246
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1998-04-09 08:00
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSTH version 5.1.2
    Test Identification PTHR.os/all/pwrite 3
    Specification System Interfaces and Headers Issue 5
    Location in Spec See Problem Text
    Problem Summary PIN5TH.00002 XSH5 is inconsistent with respect to its definition of how the signal SIGXFSZ is delivered. In one place, it says the signal is delivered to the process, and in the other it says the signal is deliver...
    Problem Text
    XSH5 is inconsistent with respect to its definition of how the signal
    SIGXFSZ is delivered. In one place, it says the signal is delivered
    to the process, and in the other it says the signal is delivered to
    a thread.

    XSH5 page 295, ftruncate() specifications says:

    If the request would cause the file size to exceed the soft limit for
    the process, the request will fail and the implementation will generate
    the SIGXFSZ signal for the process.




    XSH5 page 367, getrlimit() and setrlimit() specification says:

    RLIMIT_FSIZE This is the maximum size of a file that may be created
    by the process. If a write or truncate operation would
    cause this to be exceeded, SIGXFSZ is generated for the
    thread.

    XSH5 page 1054, write(), pwrite() and writev() specification says:

    If a write() requests that more bytes be written than there is room for
    (for example, the ulimit or physical end of medium), only as many bytes
    as there is room for will be written. For example, suppose there is
    space for 20 bytes more in a file before reaching a limit. A write of
    512 bytes will return 20. The next write of non-zero number of bytes
    will give a failure return (except as noted below) and the
    implementation will generate a SIGXFSZ signal for the thread.

    The question is which entity should receive this signal, the process
    or the thread?

    As an aside, IEEE Std 1003.1-1996 does not define the SIGXFSZ signal or
    its delivery. Now, there are implementations in which SIGXFSZ is process
    directed, as per one part of XSH5. The rationale for directing the signal
    to the process is that the resource (the file in this case) is a process-owned
    resource, and so the signal should be delivered to the process, to any
    thread that can receive it. The thread which invoked the function (say
    ftruncate()) that resulted in the generation of this signal can still
    get the indication of this problem from the error code returned by the
    function, instead of relying on the behavior of a signal handler being
    run before the function returns.

    This issue is brought up in relation to the pwrite() test 3, in the
    VSTH test suite, which expects the SIGXFSZ signal to be delivered to
    the thread before pwrite() returns.

    Instead of the "thread-directed-semantic", we believe that the
    "process-directed-semantic" makes more sense for a process-owned
    resource such as a file.

    Hence we would like the specification for getrlimit() and setrlimit(),
    and write(), pwrite() and writev() to be changed to:

    XSH5 page 367:

    RLIMIT_FSIZE This is the maximum size of a file that may be created
    by the process. If a write or truncate operation would
    cause this to be exceeded, SIGXFSZ is generated for the
    process.

    XSH5 page 1054:

    If a write() requests that more bytes be written than there is room for




    (for example, the ulimit or physical end of medium), only as many bytes
    as there is room for will be written. For example, suppose there is
    space for 20 bytes more in a file before reaching a limit. A write of
    512 bytes will return 20. The next write of non-zero number of bytes
    will give a failure return (except as noted below) and the
    implementation will generate a SIGXFSZ signal for the process.

    Test Output
    PTHR.os/all/pwrite/T.pwrite 3 Failed

    200|212 3 21:46:43|TP Start
    520|212 3 00025073 1 1|When a call to pwrite(fildes, buf, nbytes, offset) requests that
    520|212 3 00025073 1 2|more bytes be written than there is room for,
    520|212 3 00025073 1 3|then only as many bytes as there is room for shall be written
    520|212 3 00025073 1 4|and the call shall return the number of bytes written.
    520|212 3 00025073 1 5|If no bytes are written, the call shall return -1
    520|212 3 00025073 1 6|and generate a SIGXFSZ for the calling thread.
    520|212 3 00025073 1 7|XCAE ref: Component PWRITE Assertion 3(A)
    520|212 3 00025073 2 1|A SIGXFSZ was not generated
    220|212 3 1 21:46:43|FAIL
    410|212 3 1 21:46:43|IC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend that a PIN be granted on the basis of a grey area in the
    specification and that this issue be raised for clarification with the
    Base WG.


    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request should go for a 14 day anonymous review with
    the recommendation that a Permanent Interpretation is granted.


    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This is a grey area and should be addressed in a future revision
    of the specification.


    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