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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1038 Actions

    Problem Report Number 1038
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0277
    Raised 1999-08-17 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Commands and Utilities V2 (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSC version 5.0.2
    Test Identification POSIX.cmd/stty 8
    Problem Summary PG4C.00129 stty behaviour when split baud rates not supported (working group review)
    Problem Text
    This test may fail on implementations that do not support split baud
    rates, and both baud rates change when one baud rate change is made.

    For example, it is unspecified what the results of the command

    stty ispeed 9600 ospeed 2400

    is when split baud rates are not supported. The test expects the
    no baud rate changes to be made.

    We believe the behavior in the command above is implementation specific
    due to the spec's silence on this issue and due to the following statement
    found in the XCU stty command description of operands for control
    modes section

    It is unspecified whether stty will report an error
    if an attempt to set a Control Mode fails.

    Our implementation chooses the ospeed as the dominate speed and sets
    both speeds to 2400 rather than leaving the baud rate unchanged as
    the test expects. No error is reported.



    Following conversations with the consultant after this request was initially
    refused we append the following comments and submit this request for appeal.

    The consultant states that the stty request has not failed and
    the statement

    It is unspecified whether stty will report an error
    if an attempt to set a Control Mode fails.

    does not apply.

    This seems erroneous to us. The requested stty control mode was not
    set. This would be regarded as an error by anyone entering the
    command.

    The consultant goes on to state that,

    In the case of split baud rates not being supported by the
    implementation, the call to stty should modify neither the ispeed
    nor the ospeed since the call is unable to complete the requested
    action.

    The XCU does not allow for the case that the ispeed value is set
    to the requested ospeed value and does not include the concept of
    a "dominant speed" when the input and output baud rates are
    requested to be set to different values.

    There is no statement in the spec mandating this behavior. Since the
    spec is silent on this issue we believe that implementations are free
    to use whatever logic they choose to deal with a request for split baud
    rates when they are not supported. Our solution is to treat
    the ospeed value specified as the value set for both the ispeed and ospeed.

    In conversations after the initial request was refused the consultant
    also stated

    Following the trail from the specification of stty in Commands
    and Utilities, we have:

    "ispeed number .... This has the effect of setting the input
    termios baud rate values as defined in the XBD specification,
    Chapter 9, General Terminal Interface."

    and similar text for ospeed number.

    In the XBD chapter 9 we have under 9.2.4 control modes:

    "In addition, the input and output baud rates are stored in the
    termios structure. ..... The effects on the terminal device do
    not become effective and not all errors are detected until the
    tcsetattr() function is successfully called."

    This implies that the setting of the baud rate from the stty
    command has functionality equivalent to the behavior exhibited by
    tcsetattr(). This requirement is specified in XSH Section 1.9
    Utility Description Defaults under the category DESCRIPTION,
    where it states

    "When specific functions are cited, the underlying operating
    system provides equivalent functionality and all side effects
    associated with successful execution of the function."

    The description of tcsetattr() relating to baud rates states:

    "If the input and output baud rates differ and are a combination
    that is not supported, neither baud rate is changed."


    This thread of logic is forced. The stty spec references the XBD
    but there is no requirement that it use the functions listed
    there to implement its functionality. Our stty implementation does not
    rely on tcsetattr().

    Even if tcsetattr() were required the statements above need not
    apply. If the stty logic recognised that the request for split baud
    rates was unsupported and adjusted the ispeed and ospeed values
    properly the tcsetattr() call would not fail.

    In summary, we maintain that stty's behavior with regard to
    requests for split baud rates when no such feature exists is
    implementation specific because the spec is silent on the issue.

    A previous waiver, TSD4C.00175, also supports our viewpoint.
    Test Output
    ***********************************************************************
    /tset/POSIX.cmd/stty/stty.ex 1 Failed


    Test Information:
    Assertion #8 (C):
    Command failed: 'grep -q 'ispeed 9600 baud; ospeed 2400 ba
    <LC> ud;' stty_8_out'

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

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    In this case the results show that the call to stty has not failed,
    but has set the value of the ispeed to the requested value for the
    ospeed. The quoted text from the XCU deals with the case where the
    call fails to set a Control Mode, not the case where the call to stty
    has set the ispeed Control Mode to a value other than that requested.

    In the case of split baud rates not being supported by the
    implementation, the call to stty should modify neither the ispeed nor
    the ospeed since the call is unable to complete the requested action.
    The call to stty may also report an error when the call has failed.
    The XCU does not allow for the case that the ispeed value is set
    to the requested ospeed value and does not include the concept of a
    "dominant speed" when the input and output baud rates are requested
    to be set to different values.

    The quoted waiver is for release 4.1.4 of the test suite and is the
    subject of a modification in the release of VSC used in this run.
    This waiver has no relevance to this request.

    The author of the request has not provided evidence that the standard
    allows the ispeed to be set to 2400 baud when both the requested rate
    and the current were 9600 baud.

    This is not accepted as a defect in the test suite. This should be sent
    for review by the working group as a grey area in the specification, though
    we believe that the XCU specification needs to remain aligned with the
    XSH specification in regard to the treatment of split baud rates. The XSH
    specification requires that no changes are made to the baud rate for a
    request to set split baud rates on a device that does not support the
    requested rates.

    Further response from the Consultant on TSD4C.00175
    ***************************************************
    Our review of TSD4C.00175 showed the following:

    (1) It dealt with the case where, on a system that did not support split
    baud rates, the test did not allow the baud rates remain unchanged
    and no error to be reported.

    (2) The waiver referred to VSC 4.1.4 and the problem is corrected in
    the release that is being used. There is no longer a problem with
    the test.


    The problem with the customer's implementation is that it has decided to
    change the ispeed to a value which neither matches the value that the user
    requested nor the current value. We do not believe that this behaviour meets
    the requirements of the XCU which allows the implementation to either change
    the value to that requested in the command or to leave the value unchanged
    if the change is not possible. In the case that the value is left unchanged
    then the implementation may indicate an error.

    We are concerned at the implications of granting this waiver. While
    this particular problem may not be severe, the same pricipal could be used in
    other places and considerably devalue the consistency of implementations.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request is being sent for review by the Base Working Group.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The group agrees with the consultant's response. This waiver should
    not be granted. According to the specification, if ospeed and ispeed are both
    set on the command line, have different (non-zero) values, and the line
    does not support the requested split baud rates, neither ispeed nor
    ospeed should change. There is no requirement that stty return a
    non-zero exit status or that stty print an error message in this case,
    but there is nothing in the specification of the stty utility in
    XCU, the General Terminal Interface section of XBD pointed to by the
    stty utility description, or in the tcsetattr() section of XSH pointed
    to by the General Terminal Interface description that allows either
    baud rate to change if both are requested to change and the requested
    changes cannot both be successfully set on the underlying hardware.

    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