HomeAbout Us A-Z IndexSearch * Contact Us Register LoginPress Shop

The Open Brand -- Problem Reporting and Interpretations System


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


Report 1661 Actions


    Problem Report Number 1661
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0465
    Raised 1999-07-16 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSU version 5.0.4
    Test Identification CAPIbase/ioctl 25, 27, 29
    Problem Summary PG4U.00168 Request claims the test should not send zero-length message.
    Problem Text
    This IR is for the following assertions:

    ioctl 25, 27, 29


    In the tests above, a zero length message is written on the slave side of the
    pty loopback. The tests expect the master side to receive the message. However,
    page 12-24 of the Unix System V Release 4 Programmer's Guide: Streams
    states the following:

    "Since 0-length messages are used to indicate that the process on the slave
    side has closed and should be interpreted that way by the process on the master
    side, applications on the slave side should not write 0-length messages..."

    >From the statement above, it can be seen that these testcase are written
    incorrectly.

    Test Output
    TEST CASE: ioctl

    TEST PURPOSE #25
    A successful call to int ioctl(int fildes, I_SETSIG,
    int arg) when fildes refers to a STREAMS device and
    the S_RDNORM bit is set in arg shall cause the
    implementation to issue a SIGPOLL signal to the
    calling process when a zero-length normal message
    arrives at the head of the STREAM head read queue and
    return a value other than -1.
    PREP: Open master pseudo tty
    PREP: Determine if pseudo tty is a stream
    PREP: Open slave side of pseudo tty
    PREP: Catch SIGPOLL signals
    TEST: ioctl returns other than -1
    TEST: Sending zero length message generates SIGPOLL
    ERROR: SIGPOLL was not generated after write.
    25 FAIL

    TEST PURPOSE #27
    A successful call to int ioctl(int fildes, S_SETSIG,
    int arg) when fildes refers to a STREAMS device and
    the S_RDBAND bit is set in arg shall cause the
    implementation to issue a SIGPOLL signal to the
    calling process when a zero-length message with a
    non-zero priority band arrives at the head of the
    STREAM head read queue and return a value other than
    -1
    PREP: Open master pseudo tty
    PREP: Determine if pseudo tty is a stream
    PREP: Open slave side of pseudo tty
    PREP: Catch SIGPOLL signals
    TEST: ioctl returns other than -1
    TEST: Sending 0 length priority 1 message generates SIGPOLL
    ERROR: SIGPOLL was not generated after write.
    27 FAIL

    TEST PURPOSE #29
    A successful call to int ioctl(int fildes, I_SETSIG,
    int arg) when fildes refers to a STREAMS device and
    the S_INPUT bit is set in arg shall cause the
    implementation to issue a SIGPOLL signal to the
    calling process when a zero-length message other than
    a high-priority message arrives at the head of the
    STREAM head read queue and return a value other than
    -1
    PREP: Open master pseudo tty
    PREP: Determine if pseudo tty is a stream
    PREP: Open slave side of pseudo tty
    PREP: Catch SIGPOLL signals
    TEST: ioctl returns other than -1
    TEST: Sending 0 length priority 1 message generates SIGPOLL
    ERROR: SIGPOLL was not generated
    29 FAIL

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    The text from the Unix System V Release 4 Programmer's Guide should have no
    bearing on this test case for the following reasons:

    (1) The XSI definitions of putmsg() and getmsg() clearly state the expected
    behavior when a zero length data or control part is included in a message.
    The XSI requires that messages with zero length data part will be received
    by getmsg() and will not be discarded by putmsg(). The XSI also clearly
    distinguishes between messages with no data or control part and those with
    a zero length data or control part.

    (2) The text quoted from the Guide deals with the manner of interpretation
    of a zero length message by an application after it is returned in a call
    to getmsg(). The test failure shows that the message is not being returned
    by getmsg() and so a receiving process would not have the opportunity to
    make this interpretation.

    (3) The text in the Unix System V Release 4 Programmer's Guide is only a warning
    to application programmers that they SHOULD not write zero length messages.
    The reason for this warning is that the system may send a zero length
    message to indicate that the slave process has terminated. There is no
    suggestion in this text that zero length messages will either not be sent
    or will be silently ignored on the receiving side. The ability to send
    and receive zero length messages from an implication is explicitly
    required within XSI.

    It is recommended that this request is refused.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   


Contact the Certification Authority