|
Home About Us A-Z Index Search * Contact Us Register Login Press ShopThe Open Brand -- Problem Reporting and Interpretations System |
Problem Report 1661 Details
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 FAILReview 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:
- View Report 1661
- List All PRs
- Search Reports
- Email the System Administrator
- View the The Open Brand Interpretations Database User Manual
Contact the Certification Authority