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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1057 Actions

    Problem Report Number 1057
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0294
    Raised 1970-01-01 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 VSRT version 5.0.1
    Test Identification rt.os/timers/timer_settime 9
    Problem Summary PG4R.00010 Raises issues about what is returned in ovalue on a call to disarm a timer and whether rounded values must be reported in ovalue.
    Problem Text

    The test case 9 has two issues. The first test code problem
    is based on TIN4R.00003, the waiver was granted as a gray area in the
    standard that if the timer is disarmed the results from
    timer_setime() is questionable as stated on page 947 in XSH5.

    ....If the it_value member of value is zero, the timer is disarmed.
    the effect of disarming or resetting a timer on pending expiration
    notifications is unspecified.

    The test case disarms the timer with it_value member of value set to zero
    before attempting to verify the results from ovalue match the expected results.
    The second issue is within the interpretation of the standard and creating a
    test case.

    The test case 9 has the following test assertion:

    If _POSIX_TIMERS is defined or the implementation sup-
    ports the timer_settime() function as described in Sys-
    tem Interfaces and Headers, Issue 5:

    A call to timer_settime() shall round up time values
    that are between two consecutive non-negative integer
    multiples of the resolution of the specified timer to
    the larger multiple of the resolution

    The cited text continues: Quantization errors shall not cause the timer
    to expire earlier than the rounded time value. Thus the topic of the
    paragraph is the relationship between the expiration of the timer
    and the underlying clock.

    The test case code interprets the standard that the time values
    that are rounded will be returned to the user when calls to timer_settime()
    and timer_gettime() are executed. The standard does state that the
    implementation shall do rounding. It does not explicitly state that the
    internal rounding that may occur be provided to the application.


    On page 947 of XSH5, the following paragraph to the one cited above:

    If the argument ovalue is not NULL, the function timer_settime()
    stores, in the location referenced by ovalue, a value representing
    the previous amount of time before the timer would have expired
    or zero if the timer was disarmed, together with the previous timer
    reload value. The members of ovalue are subject to the resolution
    of the timer, and they are the same values that that would be
    returned by a timer_gettime() call at this point in time.


    The statement "...The members of ovalue are subject to the resolution
    of the timer.." is very unclear as to a single interpretation. One
    interpretation could be that the values must be rounded versions
    of the input arguments which is how the test case is currently coded.
    A second interpretation could be that the implementation could, as it
    chooses, provide the rounded version of the input arguments that
    it may have computed in order to achieve compliance or, because it didn't
    need to achieve compliance, simply return the exact it_interval from
    the original arguments. Under this interpretation, the implemantation
    has a choice of behavior, and the applicaion has the choice of accepting
    both behaviors.
    Test Output

    10|1 /tset/rt.os/timers/timer_settime/T.timer_settime 08:35:26|TC Start,
    scenario ref 1-0, ICs: {9}
    15|1 3.1-lite 1|TCM Start
    400|1 9 1 08:35:26|IC Start
    200|1 9 08:35:26|TP Start
    520|1 9 00010989 1 1|With resolution of 0 seconds, 1000 nanoseconds
    520|1 9 00010989 1 2|Expected value 0 seconds, 1001 nanoseconds
    520|1 9 00010989 1 3|To be rounded up to 0 seconds, 2000 nanoseconds
    520|1 9 00010989 1 4|Received 0 seconds, 1001 nanoseconds
    520|1 9 00010989 1 5|With resolution of 0 seconds, 1000 nanoseconds
    520|1 9 00010989 1 6|Expected value 0 seconds, 999999001 nanoseconds
    520|1 9 00010989 1 7|To be rounded up to 1 seconds, 0 nanoseconds
    520|1 9 00010989 1 8|Received 0 seconds, 999999001 nanoseconds
    220|1 9 1 08:35:26|FAIL
    410|1 9 1 08:35:26|IC End


    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend this request be refused on procedural grounds as it
    raises two distinct issues and the IR process has no way to deal
    with ruling on pieces of an IR separately. We recommend the submitter
    issue two separate requests if they wish to pursue one or both issues.

    In the interest of expediency it may be of use to note that we
    would also recommend both issues be refused on technical grounds.

    The first issue raised references TIN4R.00003 however we see no
    applicability of that TIN nor any grey area in the specification
    as far as this test goes.

    TIN4R.00003 deals with tests where the requirement being verified is
    that errors be raised when the reload value provided is out of range.
    The test method used happened to disarm the timer in the process
    of providing the out of range reload values and the submitter did
    not verify the reload value when the timer was being disarmed. The TIN
    was granted on the basis that there was no benefit to checking
    other input values when the timer was being disarmed.

    Here, the test is arming the timer and then disarming it, subsequently
    checking the returned ovalue from the second call, a totally
    different scenario than checking argument validation.

    Firstly we do not see where the submitter has provided results showing
    a test failure as a result of this issue. The failures shown result from
    the second issue and since no failure is involved here there is no
    branding impact and thus no basis for an IR.

    Secondly, we believe the test is correct as written in this regard.
    The spec states:

    If the argument ovalue is not NULL, the function timer_settime()
    stores, in the location referenced by ovalue, a value representing
    the previous amount of time before the timer would have expired
    or zero if the timer was disarmed, together with the previous timer
    reload value.

    The timer is armed when the second timer_settime call is made and ovalue
    is not NULL so the implementation is obliged to return the time until
    the timer would have would have expired if had not been disarmed by
    this call. The spec is clear on this and unlike the TIN issue this
    is important to the application, which wants to know what the state
    of the timer was before the change it just effected.

    In anticipation of a potential argument that since the timer was
    disarmed by this call zero should be returned, a) the implementation
    is not returning zero and b) the spec further says:

    The members of ovalue are . . the same values that would be returned
    by a timer_gettime() call at that point in time.

    and a timer_gettime call at the point in time as this timer_settime call
    is made would return the time until expiration, not 0.

    The second issue raised is a duplicate of PG4R.00008, albeit with
    slightly different results.

    As per PG4R.00008 we believe this test validates the requirements of
    the spec as written while the implementation is producing inaccurate and
    non-conforming results.

    What's being tested here is the rounded-ness of the reload value returned
    by timer_settime. The implementation has a 1000 nanosecond resolution and
    the test is giving it reload values which are not a multiple of this
    resolution and expecting them to be rounded up.

    The submitter agrees that rounding is required but argues it may return
    a different value to the application than the rounded value it is actually
    using. Specifically the submitter states:

    A second interpretation could be that the implementation could, as it
    chooses, provide the rounded version of the input arguments that
    it may have computed in order to achieve compliance or, because it
    didn't need to achieve compliance, simply return the exact it_interval
    from the original arguments. Under this interpretation, the
    implemantation has a choice of behavior, and the applicaion has
    the choice of accepting both behaviors.

    We don't see a basis for this view (nor for that matter a circumstance in
    which the implementation does not need to achieve compliance). The
    specification clearly requires the actual value which has been rounded
    to the resolution of the timer:

    <for timer_settime> The members of ovalue are subject to the
    resolution of the timer, and they are the same values that would
    be returned by a timer_gettime() call at that point in time.

    We also do not see how this gives the application a choice of accepting
    alternate behaviors. Rather it seems to just be a case of returning an
    inaccurate value to the application. This would violate the law of
    least surprise and Occam's razor, not the mention the specification.

    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