JTC1/SC22/WG14 N720

                                                ISO/IEC JTC1/SC22/WG14 N720

                    Issues related to DRs 060 to 178
                          Clive D.W. Feather


Abstract
=======

I've been looking through the defect log; specifically DRs from 060
onwards (most of which are mine :-). Apart from those you've handed out
because they said "future change", there are quite a lot that either point
out minor changes that would improve things, or that say things like "this
should be addressed at the next revision". I have put together a set of
notes and suggested changes for these.


Minor substantive changes
=========================

There are various places where a DR has indicated somewhere where the
meaning of the Standard could be improved by making a normative change
which could plausible affect some implementations. I still hope they are
uncontroversial:


DR 066
------
In 7.5.2.1 paragraph 3, insert after "of zero length":
    Apart from grouping and mon_grouping, the strings shall start and
    end in the initial shift state.


DR 070
------
In 6.3.2.2, paragraph 5, after:
    ... the types of the arguments after promotion are not compatible
    with those of the parameters after promotion, the behaviour is
    undefined.
insert:
    with one exception: if the two types are required to have the same
    representation for some or all values, the behaviour is undefined
    only if the value of the argument is not such a value. [*]

    [*] Thus a nonnegative signed integer may be passed to a parameter
    that has the corresponding unsigned type, and a pointer to void
    may be passed to a parameter with pointer to a character type.

In 6.3.2.3 paragraph 5, change "one exception" to "two exceptions", and
append:
    Secondly, if the two members have types which are required to have
    the same representation for some or all values, the value stored may
    be accessed using any member with a type for which that value must
    have the same representation.


DR 076
------
In 6.3.3.2, change the first constraint to:

    The operand of the unary & operator shall be a function designator,
    the result of a [] or unary * operator, or an lvalue that designates
    an object ...

Add to the end of paragraph 3:

    If the operand is the result of a [] or unary * operator, neither
    that operator nor the & operator are evaluated, and the result shall
    be as if both were omitted, even if the intermediate object does not
    exist.

Change the first sentence of footnote 54 to:

    Thus &*E is equivalent to E (even if E is a null pointer), and
    &(E1[E2]) to (E1+E2).


DR 084
------
In 6.5.4.3 add a constraint:

    The parameters in a parameter-type-list that is part of a function
    definition shall not have incomplete type.

and a Semantics paragraph:

    If the function declarator is not part of a function definition, the
    parameters may have incomplete type.


DRs 096 and 110

In 6.5.4.2 add a constraint:

    The element type shall not be an incomplete or function type.


DR 115
------
Change the first constraint to:

    A declaration shall declare at least a declarator (excluding the
    parameters of a function or the members of a structure or union), a
    tag, or the members of an enumeration.


DR 134
------
In 7.14.6.2, append to paragraph 2:

    If the argument is not zero, EDOM, ERANGE, or any value that a
    library function might store in errno, the behaviour is undefined.


DR 140
------
In 7.12.5.6 paragraph 2, change "any other operation" to:
    ... any other operation (except an unsuccessful call to setvbuf) ...


DR 163
------
Add a constraint to 6.3.1:

    Except for function calls as described in 6.3.2.2, there shall be a
    declaration of any identifier visible at the point it is used as a
    primary-expression.


DR 165
------
Adopt the replacement wording for 6.5.2.3 given in the DR.


DR 173
------
In 6.8.4 paragraph 2, change:
    ... to the current token.
to:
    ... up to an unspecified character within the current token.


DR 174
------
Adopt the replacement wording for 6.3.1.5 and 6.3.15 given in the DR.


DR 176
------
Adopt the replacement wording for 6.8.5 given in the DR.
[This wording makes a retained #error violate a constraint.]


Consistency and clarification changes
=====================================

These changes are intended to ensure that related parts of the Standard
are consistent with one another, or to make the text clearer and harder
to misread. All should be uncontroversial.


DR 074
------
In 6.5.2.1 paragraph 12, delete:
    "as necessary to achieve the appropriate alignment"
or append
    "or for any other purpose"
Similarly in paragraph 14.


DR 078
------
Add to 6.1.2.4:
    The address of an object is constant so long as its storage is
    guaranteed to be reserved. Two objects which are both guaranteed to
    have storage reserved at the same point in the execution of the 
    program have different addresses. Any two functions have different
    addresses.


DR 079
------
Append to 7.1.2:
    Any declaration of a library function shall have external linkage.


DR 086
------
In 7.1.7, modify the words:
    ... additionaly implemented as a macro defined in the header ...
by inserting "function-like" before "macro".


DR 109
------
In 6.3.8 paragraph 5, change:
    ... the result is undefined: ...
to:
    ... the behaviour is undefined: ...


DR 116
------
In 6.2.2.1, add to paragraph 3:
    If the array object has register storage class, the behaviour is
    undefined.


DR 132
------
Add to 3.18:
    The implementation must correctly translate a given program unless
    it can determine that every possible execution of that program would
    result in undefined behaviour.


DR 133
------
Add the list of items in the DR to subclause I.2.


DR 137
------
In 7.12.6.1 and 7.18.2.1, change footnote 173 to:
    The results of all floating conversions of a negative zero, and of
    negative values that round to zero, include a minus sign.


DR 148
------
In 7.1.7, change:
    ... so a library function should not be declared explicitly if its
    header is included.
to:
    ... so if a library function is declared explicitly when its header
    is included, one of the techniques shown below should be used to
    ensure the declaration is not affected by such a macro.


DR 151
------
In 7.12.6.1 and 7.18.2.1, '#' flag, change:
    ... the first digit of the result to be a zero.
to:
    ... the first digit of the result to be a zero (if the value and
    precision are both 0, a single 0 is printed).


DR 157
------
In 6.5.6, add a new example 4, renumbering the existing one:

    4. Typedefs can be used even where the type name is given a special
    meaning:

        typedef void NO_ARGUMENTS;
        typedef int integer;

        integer main (NO_ARGUMENTS)
        {
            /* ... */
        }

    is a valid definition of the function main in 5.1.2.2.1.


DR 160
------
In 7.1.3, paragraph 1, bullet points 2 and 5, change:
    ... reserved for use as identifiers ...
to:
    ... reserved for use as macros and as identifiers ...


DR 161
------
In 7.19, change each instance of:
    (followed by any combination of digits, letters, and underscore)
to:
    (possibly followed by ...)


DR 167
------
In 7.12.6.1 and 7.18.2.1, 'n' specifier, change the last sentence to:
    No argument is converted, but one is consumed. If the conversion
    specification with this conversion specifier is not one of %n, %ln,
    %lln, or %hn, the behaviour is undefined.

In 7.12.6.2, 'n' specifier, add %lln to the list.

In I.2, add:
    A %n conversion specification for the fprintf or fscanf functions is
    not one of %n, %ln, %lln, or %hn. (7.12.6.1, 7.12.6.2, 7.18.2.1,
    7.18.2.2).


DR 168
------
In I.2 referring to 6.3, add "a type compatible with" in the places that
TC1 changed 6.3 itself.


Difficult cases
===============

The following difficult issues are still open and need considering.


DR 063
------
What is the required precision of floating point calculations ?


DRs 072, 073 and 178

These DRs leave the issue of the "struct hack" totally confused.

One way out may be to explicitly bless the following:

    struct hack
    {
        /* other members */
        T last [];  /* Last member may be an indeterminate size array */
    }

sizeof (struct hack) would equal offsetof (struct hack, last). The
notation is an explicit warning that last will be accessed as a VLA
within malloced memory.


DR 087
------
The issue of sequence points, parallel evaluation, and so on still needs
to be faced squarely. It isn't easy [example: x = f (x++)].


DR 142
------
The Technical Corrigendum given in the DR has not been made, which is lucky,
because it misses the point. The words "unless explicitly stated otherwise"
aren't needed, because they are implicit in any reading of the Standard.

What the DR asked about is using #undef with reserved identifiers,
something which is currently strictly conforming. The following change
(suggested in the DR) is necessary to allow an implementation to make use
of flag macros such as _INCLUDED_STDIO_H.

Append to 7.1.3:

    If the program removes (with #undef) any macro definition of an
    identifier in the first group listed above, the behaviour is
    undefined.


DR 166
------
Many constraints refer to lvalues, yet the current definition can make
it impossible to tell if something is an lvalue until runtime. [6.3.2.4,
6.3.3.1, 6.3.16 are mentioned; 6.3.3.2 is addressed by DR 076 above.]


DR 172
------
There are a number of defects in the rules for pointer comparison. These
should be fixed.