SC22/WG14 N790
Changes adopted by WG14


The meaning of "implementation-defined"
Clive D.W. Feather
clive@demon.net
1997-10-21


Proposal
========
Part 1 [[other wording changes made; need to be checked]]
------
Replace 3.19 ("unspecified behavior") with:

    3.19 Unspecified behavior

    Behavior where this International Standard provides two or more
    possibilities and imposes no requirements on which is chosen in any
    instance. An otherwise correct program, operating on correct data,
    containing unspecified behaviour shall nonetheless be a correct program
    and act in accordance with subclause 5.1.2.3.

Replace 3.11 ("implementation-defined behavior") with:

    3.11 Implementation-defined behavior

    Unspecified behavior where each implementation shall document
    how the choice is made.


Part 3
------
Change 6.8.6 (Pragma directive) paragraph 1 from:

    A preprocessing directive of the form
        # pragma pp-tokens/opt new-line
    where the preprocessing token STDC does not immediately follow the
    pragma on the directive causes the implementation to behave in an
    implementation-defined manner. Any such pragma that is not recognized
    by the implementation is ignored.

to:

    A preprocessing directive of the form
        # pragma pp-tokens/opt new-line
    where the preprocessing token STDC does not immediately follow the
    pragma on the directive causes the implementation to behave in a
    manner which it shall document. The behavior might cause translation
    to fail or the resulting program to behave in a non-conforming manner.
    Any such pragma that is not recognized by the implementation is ignored.

In subclause 6.8.9 (Pragma operator), change:

    ... The original four preprocessing tokens in the unary operator
    expression are replaced by the (possibly empty) implementation-defined
    sequence of preprocessing-tokens that result from that execution.

to:

    ... The original four preprocessing tokens in the unary operator
    expression are removed.

[6.8.6 doesn't allow for preprocessing-tokens being added.]


Part 6
------
In subclause 7.13.11.4 (The perror function) paragraph 2, change:

    The contents of the error message strings are the same as those
    returned by the /strerror/ function with argument /errno/, which
    are implementation-defined.

to:

    The contents of the error message strings are the same as those
 |  returned by the /strerror/ function with argument /errno/.

[They are locale-specific, not implementation-defined.]


Part 7
------
In subclause 7.14.4.5 (The system function), change paragraphs 2 and 3
from:

    Description

    The /system/ function passes the string pointed to by /string/ to
    the host environment to be executed by a /command processor/ in an
    implementation-defined manner. A null pointer may be used for
    /string/ to inquire whether a command processor exists.

    Returns

    If the argument is a null pointer, the /system/ function returns
    nonzero only if a command processor is available. If the argument
    is not a null pointer, the /system/ function returns an implementation-
    defined value.

to:

    Description

    If /string/ is a null pointer, the /system/ function determines whether
    the host environment has a /command processor/. If /string/ is not a
    null pointer, the /system/ function passes the string pointed to by
    /string/ to that command processor to be executed in a manner which
    the implementation shall document; this might then cause the program
    calling /system/ to behave in a non-conforming manner or to terminate.

    Returns

    If the argument is a null pointer, the /system/ function returns
    nonzero only if a command processor is available. If the argument
    is not a null pointer and the /system/ function does return, it
    returns an implementation-defined value.


Part 8
------
In subclause 6.3 (Expressions) paragraph 4, change:

    These operators return values that depend on the internal
    representations of integers, and thus have implementation-defined
    aspects for signed types.

to:

    These operators return values that depend on the internal
    representations of integers, and have implementation-defined and
    undefined aspects for signed types.