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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0671 Actions

    Problem Report Number 0671
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0275
    Raised 1970-01-01 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 4.1.3
    Test Identification POSIX.upe/patch 13
    Problem Summary PG4C.00001 Same issue as IEEE POSIX.2 interpretation request #69.
    Problem Text
    This issue was the subject of IEEE POSIX.2 interpretation request #69.
    The text of that interpretation and its resolution are attached.

    ________________________________________________________________________
    PASC Interpretation refer
    1003.2-92

    ________________________________________________________________________

    Interpretation Number: XXXX
    Topic: patch -D
    Relevant Sections: 5.22


    Interpretation Request:
    -----------------------
    Date: Mon, 25 Jul 1994 15:00:03 -0700
    From: Fred Zlotnick <fred@mindcraft.com>

    I would like to an request official, binding interpretation from the
    IEEE concerning the following point in IEEE Std 1003.2-1992 (POSIX.2).

    POSIX.2 Subclause 5.22 specifies the semantics of the "patch" utility.
    In subclause 5.22.3 the behavior of the -D option is specified as
    follows:

    -D <define> Mark changes with the C preprocessor construct:

    #ifdef <define>
    ...
    #endif

    The option-argument <define> shall be used as the
    differentiating symbol.

    Can a conforming implementation of the patch utility use "#ifndef" to
    mark changes that constitute deletions from the original file? Can an
    implementation freely choose to use #ifdef or #ifndef when either is
    correct (i.e. gives a file that, after preprocessing, has the correct
    contents)? For example, the files

    aa
    #ifdef uppercase
    BB
    #else
    bb
    #endif
    cc

    and

    aa
    #ifndef uppercase
    bb
    #else
    BB
    #endif
    cc

    are equivalent in this sense. Are both valid output files from a call
    to a conforming "patch -D uppercase ..."?
    Note that the use of #ifndef is historical practice. Note also that if
    it is not permitted, implementations can still conform, but only
    through the use of such clumsy constructs as

    #ifdef <define>
    #else
    ...
    #endif

    In a similar vein: can a conforming implementation of "patch" use
    the construct

    #if defined(<define>)

    rather than

    #ifdef <define>

    In general, how broadly can the phrase "the C preprocessor
    construct:..." be interpreted?

    Thank you for your attention to this matter.

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


    The standard states the behaviour for #ifdef and #endif and conforming
    implementations must conform to this. The standard makes no restrictions
    for the use of further C preprocessor directives between #ifdef and #endif
    The standard does not allow using #ifndef and #if defined in the manner
    specified in the interpretation request. Concerns about this are being
    refered to the sponsor.


    Rationale for Interpretation:
    -----------------------------
    None.

    Forwarded to Interpretations group: 26 Jul 94

    Proposed resolution sent for review: 19th Nov 94
    Resolved: 10th Dec 94

    Test Output
    ***********************************************************************
    400|1 13 1 10:54:32|IC Start
    200|1 1 10:54:33|TP Start
    520|1 1 3670034 1 1|Assertion #13 (C):
    520|1 1 3670034 1 1|Note: The behavior associated with this assertion is expecte
    520|1 1 3670034 1 2|to change in a future revision of POSIX.2.
    520|1 1 3670034 1 3|-TC13- Output differs from the expected output
    220|1 1 1 10:54:50|FAIL
    410|1 13 1 10:54:51|IC End

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

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    Not enough information has been supplied. The test output details are
    required so the actual behaviour of the implementation can be considered
    permitted and a Permanent Interpretation granted.

    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