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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0727 Actions

    Problem Report Number 0727
    Submitter's Classification Specification problem
    State Resolved
    Resolution Temporary Interpretation (TIN)
    Problem Resolution ID TIN.X.0018
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1996-01-26 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 99 100
    Specification Commands and Utilities Issue 4 Version 2
    Location in Spec See Problem Text
    Problem Summary TIN4C.00043 This test may fail on IUTs because POSIX.2 IR #43 ruled the treatment of subexpressions and backreferences ambiguious.
    Problem Text
    This test may fail on IUTs because POSIX.2 IR #43 ruled the
    treatment of subexpressions and backreferences ambiguious.

    The test is unexpectedly matching the expression a\(b\)*\1 when
    presented the string "acb" and matching "ac".

    POSIX.2 interpretation 1003.2-92 #43 addresses the following issue:

    ---------------------------------------------------------------------------
    [15] To which match is a backreference to a duplicated
    subexpression bound? [2.8.3.3(4)]

    Proposed Solution:

    A backreference to a subexpression contained in a duplication is bound
    to the (possibly nonexistent) match to the subexpression in the most
    recent iteration of the duplication. Thus \(\(.\)\2\)* matches
    xxyyzz, with \2 refer- ring to x, y, and z respectively in the three
    iterations of the outer subexpression. However, \(\(.\)*\2#\)*
    matches only the first six characters of xx#yy##, because in a third
    iteration of the outer subexpression, . would match nothing (as
    distinct from matching a null string) and hence \2 would match
    nothing.

    Rationale:

    Current implementations agree on this interpretation, which is a
    natural generalization of binding in regmatch structures by regexec().
    [B.5.2]

    IEEE Interpretation for 1003.2-1992
    -----------------------------------

    Part 14:

    The text on page 82, lines 2975-2979, and page 77, lines 2791-2796 are
    in conflict and as such the standard is unclear on this issue, and no
    conformance distinction can be made between alternative
    implementations based on this. This is being referred to the sponsor.
    ---------------------------------------------------------------------------

    The referred to text in XBD section 7.3.6 states,

    2. A subexpression can be defined within a BRE by
    enclosing it between the character pairs \( and
    \) . Such a subexpression matches whatever it
    would have matched without the \( and \), except
    that anchoring within subexpressions is optional
    behaviour; see Section 7.3.8 on page 158.
    Subexpressions can be arbitrarily nested.
    [...]
    4. When a BRE matching a single character, a
    subexpression or a back-reference is followed by
    the special character asterisk (*), together
    with that asterisk it matches what zero or more
    consecutive occurrences of the BRE would match.
    For example, [ab]* and [ab][ab] are equivalent
    when matching the string ab.

    The implementation is treating the "\(b\)*" as a single expression
    because of statement 4.
    Test Output
    ***********************************************************************
    /tset/POSIX.cmd/expr/expr.ex 1 Failed


    Test Information:
    Assertion #99 (A): GA136
    Note: An IEEE POSIX.2 interpretation request is pending on
    'nothing will be written to indicate a null string'.
    Testing regular expression "\\(a\\(b\\(c\\(d\\(e\\)\\)\\)\\
    <LC> )\\)\\4"
    Testing regular expression "a\\(b\\)*c\\1"
    expected exit status 1, got 0
    Contents of regb_err:
    output differed from expected
    Expect output: ""
    Actual output: "2"
    Testing regular expression "\\(a\\(b\\(c\\(d\\(e\\(f\\(g\\)
    <LC> h\\(i\\(j\\)\\)\\)\\)\\)\\)\\)\\)\\9"

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

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


    Test Information:
    Assertion #100 (A): GA137
    Note: An IEEE POSIX.2 interpretation request is pending on
    'nothing will be written to indicate a null string'.
    Testing regular expression "a\\(b\\)*c\\1"
    expected exit status 1, got 0
    Contents of regb_err:
    output differed from expected
    Expect output: ""
    Actual output: "2"

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

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    Because POSIX.2 interpretation #43 ruled this issue to be ambiguous in
    the standard, 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