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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1974 Actions

    Problem Report Number 1974
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0237
    Raised 1996-08-08 08:00
    Updated 2003-03-13 08:00
    Published 1996-10-03 08:00
    Product Standard Transport Service XTI
    Certification Program The Open Brand certification program
    Test Suite VST version 4.1.4
    Test Identification XTI.os/cots/accept 21
    Specification Networking Services Issue 4
    Location in Spec See Problem Text
    Problem Summary PINT4.003 (This could also be considered to be a grey area in the spec, based on feedback from the vst_support alias, which reveals confusion about interpreting certain words.) For certain parameters to t_*() r...
    Problem Text

    (This could also be considered to be a grey area in the spec, based
    on feedback from the vst_support alias, which reveals confusion
    about interpreting certain words.)

    For certain parameters to t_*() routines which are of type "struct netbuf"
    that receive an "incoming value", the usual semantics are that the
    "len" field is initialized to the size of the value copied in "buf" and
    the "maxlen" is the upper bound which if exceeded, generates TBUFOVFLW
    error. If the caller is not interested in receiving this incoming parameter,
    then "maxlen" is initialized to zero and the "incoming value" is not
    initialized and neither is any TBUFOVFLW error returned. The implementation
    leaves the "len" and "buf" fields untouched.

    For such instances where the test suite is not interested in the "incoming
    value", it initializes the "maxlen" to zero and "buf" to NULL. It
    however NEGLECTS to initialize the len field to zero. The "struct netbuf"
    is usually a variable in a subroutine and therefore on the stack of the
    calling program and contains whatever uninitialized junk that exists.
    At some point later in the test, sometimes this "struct netbuf" is passed
    to a t_*() routine where it is parsed as an initialized input parameter and
    the uninitialized junk in the "len" field gets interpreted as the length
    of the "buf" part. It is possible that on some platforms the uninitialized
    junk might happen to be 0 and this problem will go unnoticed.

    The T.accept (21) test case, the "callret" variable is first
    initialized as described above and used to receive "incoming value"
    from t_listen(). Later it is passed to t_accept() with the "len"
    field containing uninitialized junk which fails.

    We think the "len" parameter should either be intialized before
    even passed to t_listen() or atleast before being passed to t_accept().

    We have made the following modification to do_incon() routine
    in vst/SRC/common/tsetlib/provsetup.c file on MASTER to achieve the
    desired results (new lines marked as <======= NEW ).

    private int
    do_incon(fd, curr_prov, callret)

    ......
    if (callret != NULL)
    {
    callret->opt.buf = NULL;
    callret->opt.maxlen = 0;
    callret->opt.len = 0; <====== NEW
    callret->udata.buf = NULL;
    callret->udata.maxlen = 0;
    callret->udata.len = 0; <====== NEW
    if (addralloc(&callbuf, &callret->addr) != 0)
    DBUG_RETURN(-1);
    else
    PATH_TRACE;
    }
    ......
    }
    With this change, the test output is:

    10|0 /tset/XTI.os/cots/accept/T.accept 14:23:06|TC Start, scenario ref 4-1, ICs
    {21}
    15|0 2.3 1|TCM Start
    400|0 21 1 14:23:08|IC Start
    200|0 21 14:23:08|TP Start
    220|0 21 0 14:23:08|PASS
    410|0 21 1 14:23:08|IC End
    80|0 0 14:23:08|TC End
    820||Remote End
    900|14:23:09|TCC End

    Test Output
    There is no output from this test case since the test case
    ends prematurely with a segmentation violation...

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    This seems to be a grey area in the specification, and it is recommended
    that this issue should be referred to the XNET working group.

    The issue is the precise meaning of the phrase "no information is returned"
    in the following text from the corrigenda (CR XTI-1.7). This text is
    for t_listen() - there is similar text for the other affected functions.

    `If the maxlen field of call->addr, call->opt, or call->udata is set
    to zero, no information is returned for this parameter.'

    The VST test suite expects that the implementation will set call->udata.len
    to zero when t_listen() is called with call->udata.maxlen equal to zero
    and call->udata.len greater than zero. An implementation that does not
    set call->udata.len to zero can be considered to have returned some
    information in call->udata, contrary to the requirement that no
    information is returned when maxlen is zero.

    Another part of the specification which may have some bearing is the
    following (again for t_listen(), with similar text for other functions):

    `Since this function returns values for the \fIaddr\fP, \fIopt\fP and
    \fIudata\fP fields of \fIcall\fP, the \fImaxlen\fP field of each
    must be set before issuing the t_listen() to indicate the maximum
    size of the buffer for each.'

    If the application is required to set the "len" field to zero when "maxlen"
    is zero, then this ought to be stated here.

    Since VST has been run successfully on many different systems, it seems
    likely that most (if not all) of these systems are setting the "len" field
    to zero in this situation. (VST could run successfully on a system which
    does not do this, if the value of the "len" field always happens to be zero.)

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    Resolution XNET45-4:

    Having considered the interpretation request req.xti.4.1.038 (which was sent
    out wrongly labelled as req.4.U.00233) against the XNS contained in
    XoTGnet 5829, XNET concludes that there is a grey area in the XNS relating
    to the use of the len field in returned netbuf structures and recommends
    that a Permanent Interpretation be granted, indicating that the implementation
    need not set the len field to zero under the circumstances described in
    the interpretation request.

    This was approved unanimously.

    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