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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0740 Actions

    Problem Report Number 0740
    Submitter's Classification Specification problem
    State Resolved
    Resolution Temporary Interpretation (TIN)
    Problem Resolution ID TIN.X.0031
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1995-10-30 08:00
    Product Standard Commands and Utilities V2 (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSC version 4.1.4
    Test Identification POSIX.cmd/expr 77
    Specification Commands and Utilities Issue 4 Version 2
    Location in Spec See Problem Text
    Problem Summary TIN4C.00030 The test may fail on implementations that adhere to POSIX.2b behavior and generate an empty line instead of nothing. See also TIN4C.00019.
    Problem Text
    The test may fail on implementations that adhere to POSIX.2b
    behavior and generate an empty line instead of nothing.

    The test in question depends on the output of expr when an attempt is
    made to match a string using the subexpression syntax and the matched
    string is a null string (i.e. there is no match). In this case,
    POSIX.2 states (and XCU4 repeats):

    The character '0' shall be written to indicate a zero
    value and nothing shall be written to indicate a null
    string.

    (POSIX.2 subclause 4.22.6.1.) This differs from historic practice. An
    IEEE Interpretation Request was made regarding this issue, and the
    resolution of this request was:

    The standard is clear that a nl is not appended to the results of
    the evaluation in any case. This is not historical behavior,
    however, conforming implementations must conform to this. However,
    concerns have been raised about this which are being referred to
    the sponsor.

    (The complete text of the interpretation request and response are
    attached.) In view of the last sentence, as well as the fact that this
    differs from historic practice, this is clearly a grey area. Note that
    in the most recent draft of POSIX.2b (Draft 11), the language has been
    changed to require the historic behavior.

    Note: the waiver requested here is identical to one previously requested
    for assertions 60,65,99,100,102,105,107,108,109,110,114,120 and 125.
    Assertion 77 was inadvertently omitted from this list.

    Here is the text of IEEE Interpretation pasc-1003.2-105:
    -----------------start of interpretation-------------------
    _____________________________________________________________________________
    (c) 1995 The Institute of Electrical and Electronic Engineers, Inc.
    Not to be published without prior written permission of the IEEE.
    _____________________________________________________________________________

    To: Chuck Hickey
    From: Andrew Josey, PASC Interpretations Vice-Chair
    Reference: PASC 1003.2-92 #105


    Dear Sir.

    Subject: IEEE Standard 1003.2-1992

    Enclosed is the official response for your request for an interpretation
    of IEEE Standard 1003.2-1992:
    Topic: expr standard output representing a null string
    Relevant Sections: 4.22.6.1

    This response was developed and approved by the members of the 1003.2
    Interpretations Committee.

    Please can you confirm receipt of this electronic mail message
    within ten working days, please carbon copy your response to the IEEE
    (stds.pasc-ieee-officers@ieee.org)

    Sincerely,


    Andrew Josey
    PASC VC Interpretations

    Enclosures


    Cc: IEEE PASC Officers
    Don Cragun, Chair, P1003.2

    _____________________________________________________________________________
    (c) 1995 The Institute of Electrical and Electronic Engineers, Inc.
    Not to be published without prior written permission of the IEEE.




    _____________________________________________________________________________
    PASC Interpretation reference
    1003.2-92 #105

    _____________________________________________________________________________

    Interpretation Number: XXXX
    Topic: expr standard output representing a null string
    Relevant Sections: 4.22.6.1

    Interpretation Request:
    -----------------------

    Date: Tue, 4 Apr 1995 17:37:40 -0700
    From: Chuck.Hickey@Eng.Sun.COM (Chuck Hickey [CONTRACTOR])

    Dear Standards Board,
    I would like to request a formal interpretation on the following
    issue concerning the expr utility in POSIX.2.

    Standard: IEEE Std 1003.2-1992
    Topic: expr standard output representing a null string
    Relevant Sections: 4.22.6.1

    In IEEE Std 1003.2-1992 section 4.22.6.1 (Standard Output of
    the expr utility), P276, L4127-4129, the description of the
    standard output representing expressions evaluating to zero and
    to null strings is:
    The character '0' shall be written to indicate a zero
    value and nothing shall be written to indicate a null
    string.

    This could be interpreted literally to mean that the output in
    these two cases must not include a newline character. (At
    least one developer of a POSIX.2 test suite has used this
    interpretation for the null string, but not for '0'.)

    In both BSD and System V historic practice, an expression
    evaluating to zero produced "0\n" on standard output and an
    expression evaluating to a null string produced an empty line
    on standard output.

    The rationale in section E.4.22, P904, L6209-6213 acknowledges
    that expr could be replaced by other shell constructs in the
    POSIX.2 shell, but says the utility was kept because of the
    many historical shell scripts that use it. The rationale also
    mentions that other changes in early drafts of the standard
    were backed out because they weren't historic practice
    (see L6229-6230). It seems strange that this change to
    historical practice was not documented if it was intentional.

    To match historic BSD and System V implementations, the
    second sentence of the Standard Output section on P276,
    L4128-2129 should have been something like:
    An empty line shall be written to indicate a
    null string.
    Note that the zero case is already handled in the first sentence
    in that section.

    Was this change to historic practice intentional?




    Interpretation response
    ------------------------
    The standard is clear that a nl is not appended to the results of the
    evaluation in any case. This is not historical behavior, however,
    conforming implementations must conform to this. However, concerns
    have been raised about this which are being referred to the sponsor.



    Rationale:
    None
    Proposed resolution circulated: May 16th
    Comments due: June 15th
    Finalised: June 16th 1995

    ------------------end of interpretation--------------------
    Test Output
    -----------------start of test output------------------

    ************************************************************************
    /tset/POSIX.cmd/expr/expr.ex 1 Failed


    Test Information:
    Assertion #77 (A): GA114
    Note: An IEEE POSIX.2 interpretation request is pending on
    'nothing will be written to indicate a null string'.
    Note: An IEEE POSIX.2 interpretation request is pending on
    behavior of the caret (^) anchor in an expr BRE
    Testing regular expression "a^b"
    Testing regular expression "a\^b"
    Testing regular expression "^^"
    expected exit status 1, got 0
    Contents of regb_err:
    output differed from expected
    Expect output: "0"
    Actual output: "1"
    Testing regular expression "\^"
    Testing regular expression "[c^b]"
    Testing regular expression "[\^ab]"
    Testing regular expression "[\^ab]"
    Testing regular expression "[^^]"
    Testing regular expression "\(a^b\)"
    Testing regular expression "\(a\^b\)"
    Testing regular expression "\(\^\)"
    output differed from expected
    Expect output: ""
    Actual output: ""
    ************************************************************************

    ------------------end of test output-------------------

    Note about the output shown above:
    ----------------------------------
    This is taken from the output of the vrpt report. There are two
    different failures. Only the second, in which the BRE under test is
    "\(\^\)", has as its root cause the problem cited in this request.
    (The first failure is addressed by TSD4C.00085.) In this test the
    expression is matched against the string "a^b" and the correct expected
    output is a non-match. In these cases our system writes a single
    newline character.

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    Anticipating acceptance of the modified expr specification
    in POSIX 2003.2b/D11 and the eventual alignment of the tests with it
    a temporary interpretation is recommended.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Temporary Interpretation (TIN)
    Review Conclusion
    A Temporary Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority