Results of discussion on ISO/IEC JTC1/SC22/WG14 N739

                General wording issues (clauses 1 to 6)
                            First Revision
                          Clive D.W. Feather


Of the 16 items in this paper, 10 were approved, in some cases with wording
changes; the final edits to the Standard are given below. The remaining
items were dealt with as follows:

    Item 1:  deferred pending specific wording proposals
    Item 7:  WG14 was unconvinced of the need for this change
    Item 9b: deferred pending N732
    Item 11: not discussed
    Item 12: not discussed
    Item 13: not discussed

These items will be re-presented in new papers.


Specific wording changes
========================

Item 2:

Change the first part of paragraph 1 of subclause 5.1.2.2.1 to:

    The function called at program startup is named /main/. The
    implementation declares no prototype for this function. It shall be
    defined either with no parameters:

    ...

        int main (int argc, char *argv[]) { /* ... */ }

    or equivalent [*], or in some other implementation-defined manner.

    [*] Thus /int/ can be replaced by a typedef-name defined as /int/,
    or the type of argv can be written as /char **argv/, and so on.

====

Item 3:

In subclause 5.1.2.3, example 2, change:

    Provided the addition of two /chars/ can be done without creating
    an overflow exception, ...

to:

    Provided the addition of two /chars/ can be done without overflow,
    or with overflow wrapping silently to produce the correct result, ...

In example 6, change:

    On a machine in which overflows produce an exception ...

to:

    On a machine in which overflows produce an explicit trap ...

and change:

    However on a machine in which overflows do not produce an exception
    and in which the results of overflows are reversible,

to:

    However, on a machine in which overflow silently generates some
    value and where positive and negative overflows cancel,

====

Item 4:

In 5.2.1 paragraph 2, delete the final "literal".

Add a forward reference to "string" in 7.1.1.

====

Item 5:

In 6.1.2 paragraph 4, change:

    An identifier denotes an object ... or a macro parameter.

to:

    An identifier can denote an object ... or a macro parameter.
    The same identifier can denote different entities at different
    points in the program.

In 6.1.2.1 paragraph 1, change:

    An identifier is /visible/ (i.e. can be used) only within a region
    of program text called its scope.

to:

    For each different entity that an identifier designates, the
    identifier is /visible/ (i.e. can be used) only within a region of
    program text called its scope. Different entities designated by
    the same identifier either have non-overlapping scopes, or are
    in different name spaces.

In paragraph 3, change:

    If an outer declaration of a lexically identical identifier
    exists in the same name space, it is hidden until the current
    scope terminates, after which it again becomes visible.

to:

    If an identifer designates two different entities in the same name
    space, the scopes might overlap. If so, the scope of one entity
    (the /inner scope/) will be a strict subset of the scope of the
    other entity (the /outer scope/). Within the inner scope, the
    identifier designates the entity declared in the inner scope; the
    entity declared in the outer scope is /hidden/ (and not visible)
    within the inner scope.

Insert a new paragraph between paragraphs 3 and 4:

    Unless explicitly stated otherwise, where this International Standard
    uses the term "identifier" to refer to some entity (as opposed to the
    syntactic construct), it refers to the entity in the relevant name
    space whose declaration is visible at the point that the identifier
    occurs.

In 7.1.3 paragraph 2, change:

    If the program declares or defines an identifier with the same
    name as an identifier reserved in that context ...

to:

    If the program declares or defines an identifier that is reserved
    in that context ...

====

Item 6a:

In 6.1.2.5, append to paragraph 11:

    The implementation shall define /char/ to have the same range,
    representation, and behavior as one of /signed char/ and /unsigned
    char/. [*]

    [*] CHAR_MIN, defined in <limits.h>, will have one of the values 0
    or SCHAR_MIN, and this can be used to distinguish the two options.
    Irrespective of the choice made, /char/ is a separate type from the
    other two, and is not compatible with either.

====

Item 6b:

In 6.1.2.5, change the last sentence of paragraph 2 from:

    If other quantities are stored in a /char/ object, the behavior
    is undefined; the values are treated as either signed or nonnegative
    integers.

to:

    If any other character is stored in a /char/ object, the resulting
    value is implementation-defined but shall be within the range of
    values that can be represented in that type.

====

Item 8:

Add the following to the end of subclause 6.2.2.3:

    An integer may be converted to any pointer type. The result is
    implementation-defined, and might not be a pointer to an object
    of that type. [59]

    Any pointer type may be converted to an integral type; the result is
    implementation-defined, and need not be in the range of values of
    any integral type. If the resulting value cannot be represented in
    the destination type, the behavior is undefined. [*]

    [*] Thus if the conversion is to /unsigned int/ but yields a
    negative value, the behavior is undefined.

    A pointer to a complete or incomplete object type may be converted
    to a pointer to a different complete or incomplete object type. If
    the resulting pointer is not correctly aligned for the pointed to
    type, the behavior is undefined. Otherwise, when converted back
    again, the result shall compare equal to the original pointer. [*]

    [*] All pointers to character types are correctly aligned. In
    general, the concept "correctly aligned" is transitive: if a pointer
    to type A is correctly aligned for a pointer to type B, which in
    turn is correctly aligned for a pointer to type C, then a pointer to
    type A is correctly aligned for a pointer to type C.

    A pointer to a function ... [this paragraph, taken from 6.3.4,
    remains unchanged].

Delete 6.3.4 paragraph 4, and add the following paragraph to the
constraints (after paragraph 2):

    Conversions that involve pointers, other than where permitted by the
    constraints of 6.3.16.1, shall be specified by means of an explicit
    cast.

====

Item 9a:

In 6.3.2.3 paragraph 5, replace:

    With one exception, if a member of a union object is accessed after
    a value has been stored in a different member of the object, the
    behavior is implementation-defined. [53] One special guarantee is
    made ...

with:

 |  With one exception, if the value of a member of a union object is
 |  used when the most recent store to the object was to a different
 |  member, the behavior is implementation-defined. [53] One special
    guarantee is made ...

====

Item 10:

Replace subclause 6.5.2 paragraph 4 by:

    Each of the comma-separated sets designate the same type, except
    that for bit-fields, it is implementation-defined whether the
    specifier /int/ is the same type as /signed int/ or is the same
    type as /unsigned int/.

Replace subclause 6.5.2.1 paragraph 8 by:

    A bit-field shall have a type that is a qualified or unqualified
    version of /signed int/ or /unsigned int/. A bit field is
    interpreted as a signed or unsigned integral type consisting of the
    specified number of bits. [*]

    [*] As specified in 6.5.2 above, if the actual type specifier used
    is /int/ or there is no type specifier, or is a typedef-name defined
    using either of these, then it is implementation-defined whether the
    bit-field is signed or unsigned.

====

Item 14:

Change subclause 6.6.6.4 as follows. Append to the Constraints:

    A /return/ statement without an expression shall only appear in a
    function whose return type is /void/.

Change paragraph 2, last sentence, from:

    A function may have any number of /return/ statements, with and
    without expressions.

to:

    A function may have any number of /return/ statements.

Change 6.6.6.4 paragraph 4 from:

    If a /return/ statement without an expression is executed, and the
    value of the function call is used by the called, the behavior is
    undefined. Reaching the } that terminates a function is equivalent
    to executing a /return/ statement without an expression.

to:

    If the } that terminates a function is reached, and the value of the
    function call is used by the caller, the behavior is undefined.

and change the last sentence of subclause 5.1.2.2.3 from:

    If the /main/ function executes a return that specifies no value,
    the termination status returned to the host environment is undefined.

to:

 |  If the } that terminates the /main/ function is reached,
 |  the termination status returned to the host environment is unspecified.