ISO/ IEC JTC1/SC22/WG14 N807

Document Number: N807	J11/98-006
Title:  CD1 public comments (US 001-006, UK 001-073)
Date: 25 February 1998

----------------------------------------------------------------------
UK Public Comments
----------------------------------------------------------------------
Public Comment Number PC-UK0001
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-27
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: various

Title: Errors in applying working papers to CD1

Detailed description:

This document lists the errors that have been made applying my approved
papers in CD1. They are listed in this Public Comment for the record.


N672 has not been applied.

The change to translation phase 2 in N673 has been made, but the footnote
has been lost.

7.1.8p3 should read "... returns.", not "... return"; see N675 DR147 for
details. The same correction is needed in annex C.

Footnote 30 should read "... and is not compatible with either.", not
"and it not compatible with either.". The change was introduced in N739
item 6a.

6.5.2p4 should read "... the specifier /int/ ...". The change was
introduced in N739 item 10.

7.16.3.6p6 should read "%p", not "%P" (this was introduced in N674 part G).
It is also inconsistent in its use of fonts - compare %B and %p.

7.11p3 has been misedited; it reads:
    ... which expand to positive integer constant expressions with type
    /int/ and distinct values that have type compatible ... which expand
    to positive integer constant expressions with distinct values that
    are the signal numbers ...
and should read:
    ... which expand to constant expressions with distinct values that
    have type compatible ... which expand to positive integer constant
    expressions with type /int/ and distinct values that are the signal
    numbers ...
The change was introduced in N773 item 9B.

6.3.15p4 to p6 have not been changed as required by N774 item 1.

6.5.2.3p4 should read "The type is incomplete[94]", not "The type is
complete[94]". The change was introduced in N774 item 5.

Footnote 227 is missing the last line:
    (char *) p < (char *) base + nmemb * size
The change was introduced in N783 item 13.

The changes relating to _exit() in N789 were omitted (at the discretion
of the editorial committee). These will be resubmitted as a separate
Public Comment.

7.16.1p1 should read "... and declares five types ...", not "... and
declares four types ...". The change was introduced in N793.

The comment within the pseudo-code in 7.16.2.6p3 is missing the last line,
which should read:
    // if the offset cannot be determined.
The change was introduced in N793, though this also seems to be missing
that line.

----------------------------------------------------------------------
Public Comment Number PC-UK0002
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-27
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Other: correction restoring original intent
Committee Draft subsection: 6.5.2.1

Title: Padding in unions - wording adjustment

Detailed description:

6.5.2.1p14 no longer makes sense. The words:
    were the structure or union to be an element of an array
should be deleted.

----------------------------------------------------------------------
Public Comment Number PC-UK0003
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-27
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 6.3.2.2

Title: Adjustment to permitted incompatible argument types

Detailed description:

The excepted cases in 6.3.2.2p5 were meant to be slightly less restrictive
than the wording given. The second bullet point should read:
    - both types are pointers to qualified or unqualified versions of /void/
      or of character types.

In addition, paragraph 6 should be part of paragraph 5; it is easy to
misparse the present arrangement. It could also be made easier by changing
the first words of the paragraph to:
    Furthermore, if the function ...

----------------------------------------------------------------------
Public Comment Number PC-UK0004
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-27
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.7

Title: Shift operators - wording tidy up

Detailed description:

Now that the term "width" is available, 6.3.7p3 could be reworded; the
last sentence should read:
    If the value of the right operand is negative or is greater than or
    equal to the width of the promoted left operand, the behavior is
    undefined.

----------------------------------------------------------------------
Public Comment Number PC-UK0005
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-25
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 3.18, 6.8.5

Title: Make #error have the desired effect

Detailed description:

Consider the program:
    #error foo
    int main(void) { return 0; }

This does not violate any of 3.18p3:

    The implementation must successfully translate a given program unless
    a syntax error is detected, a constraint is violated, or it can
    determine that every possible execution of that program would result
    in undefined behavior.

but clearly ought to. A reasonable way to fix this is to add to the end of
3.18p3:

    The implementation must not successfully translate a program that
    contains a #error preprocessing directive that is not part of a
    group that is skipped by conditional inclusion.

----------------------------------------------------------------------
Public Comment Number PC-UK0006
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-27
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.4

Title: Clarification concerning overlapping string literals

Detailed description:

The first sentence of 6.1.4p6 does not fall into any of the three types of
behavior. Better wording would be:

    It is unspecified whether these arrays overlap or not, provided that
    their characters have the appropriate values.

----------------------------------------------------------------------
Public Comment Number PC-UK0007
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-27
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Other: outstanding problem
Committee Draft subsection: 6.5.3.1

Title: Problem with restrict and string literals

Detailed description:

Consider the function call:

    fopen ("bar", "r");

Because both parameters of fopen() have restrict-qualified type, it is not
permitted for the two strings to share storage. However, an implementation
which shares string literals might do so, possibly without the programmer
realizing that the situation happened (for example, the first parameter
might be a macro defined in a makefile).

The correct solution is to exempt string literals from the rules concerning
restrict, but I am not familiar enough with the wording to try.

----------------------------------------------------------------------
Public Comment Number PC-UK0008
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Other: moving normative text to a normative section
Committee Draft subsection: Introduction, 1

Title: The definition of normative text should be normative.

Detailed description:

The Introduction contains the text:

    The introduction, the examples, the footnotes, the references,
    and the annexes are not part of this International Standard.

However, this text is not normative, and so it is not clear what text is
and is not normative. It is also wrong.

Delete the sentence from the Introduction. Add a new paragraph 3 to clause
1:

    Annexes F and I are normative. The introduction, the examples, the
    footnotes, the references, and the remaining annexes are not part of
    this International Standard.

----------------------------------------------------------------------
Public Comment Number PC-UK0009
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 7.16.3.6

Title: Lacuna in strftime() %z

Detailed description:

The description of %z does not say what to do if no time zone can be
determined. After the parenthesized clause, insert the words:

    or no characters if no time zone is determinable.

----------------------------------------------------------------------
Public Comment Number PC-UK0010
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 7.16.1

Title: _NO_LEAP_SECONDS should require a sensible value

Detailed description:

After the symbol _NO_LEAP_SECONDS in 7.16.1p2, add the comment:

    _NO_LEAP_SECONDS // must be outside the range [-3600, +3600]

----------------------------------------------------------------------
Public Comment Number PC-UK0011
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 7.16.1

Title: require a type for _NO_LEAP_SECONDS and _LOCALTIME.

Detailed description:

At the end of 7.16.1p2 add the words:

    which are integral constant expressions with type /int/.

----------------------------------------------------------------------
Public Comment Number PC-UK0012
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 7.16.1

Title: Fix definition of "broken-down time".

Detailed description:

The term "broken-down time" is clearly intended to refer to both the
types "struct tm" and "struct tmx". Change the last part of 7.16.1p3
from:

    ... representing times;

    /struct tm/

    which holds the components of a calendar time, called the /broken-
    down time/; and

    /struct tmx/

    which is an extended version of /struct tm/.

to:

    ... representing times; and

    /struct tm/

    and

    /struct tmx/

    which hold the components of a calendar time, called the /broken-
    down time/, in two slightly different ways.

----------------------------------------------------------------------
Public Comment Number PC-UK0013
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 6.1.2.5, 6.5.2.1

Title: Cleanup of flexible array structure members.

Detailed description:

The concept of flexible array structure members, otherwise known as the
"struct hack", has a number of minor problems that need fixing.
Furthermore, there are some nasty implications when such a structure is
used as a component of an aggregate type, this is forbidden.

6.1.2.5p17, bullet point 2, should read:

    A /structure type/ describes a sequentially allocated nonempty
    set of member objects (and, in certain circumstances, an incomplete
    array), each of which has an optionally specified name and possibly
    distinct type.

6.5.2.1p2, first sentence, should read:

    ... except that the last member of a structure with more than
    one named member may have incomplete array type; such a structure
    (and any union containing, possibly recursively, a member whose type
    is such a structure) shall not be the type of a member of a structure
    or of the element of an array.

6.5.2.1p15 should be replaced by:

    As a special case, the last member of a structure with more than
    one named member may have an incomplete array type. This is called a
    /flexible array member/, and the size of the structure shall be
    equal to the offset of the last member of an otherwise identical
    structure that replaces the flexible array member with an array of
    unspecified length [*]. When an lvalue whose type is a structure with
    a flexible array member is used to access an object, it behaves as if
    that member were replaced with the longest array, with the same
    element type, that would not make the structure larger than the object
    being accessed; the offset of the array shall remain that of the
    flexible array member, even if this would differ from that of the
    replacement array. If this array would have no elements, then it
    behaves as if it had one element, but the behavior is undefined if any
    attempt is made to access that element or to generate a pointer one
    past that element.

    [*] The length is unspecified to allow for the fact that some
    implementations may give array members different alignments according
    to their length.

Change the start of paragraph 16 to:

    Assuming that all arrays have the same alignment within structures,
    then after the declarations:

        struct s { int n; double d[]; };
        struct ss { int n; double d[42]; };

    the three expressions:

In paragraph 17, change:

    /s1/ and /s2/ behave as if they had been declared as:

to:

    the objects pointed to by /s1/ and /s2/ behave as if the latter two
    identifiers had been declared as:

----------------------------------------------------------------------
Public Comment Number PC-UK0014
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.5.8

Title: problems with initializing unsigned char arrays.

Detailed description:

Consider the following declaration:

    unsigned char s [] = "\x80\xff";

The first element of the string literal has the value:

    (char) 128

and the second element has the value:

    (char) 255

If the type char is signed and CHAR_MAX is less than 128, these two
expressions are implementation-defined. In particular, on a ones-
complement implementation likely values are -127 and -0 respectively.
When these are converted back to unsigned char during the initialization,
then (if UCHAR_MAX is 255) they will be converted to 129 and 0 respectively.
This is *not* intuitive.

Append to 6.5.8p17:

    The value of each element is determined by converting the corresponding
    numerical representation of the mapped character, or the octal or
    hexadecimal escape sequence, directly to the array element type,
    not via the type char.

Append to example 7 in 6.5.8p24:

    The declaration:

        unsigned char c [] = "\xFF";

    is identical to:

        unsigned char c [2] = { 0xFF, 0 };

    and not to:

        unsigned char c [2] = { (unsigned char)(char) 0xFF, 0 };

    (the latter could be different if /CHAR_MAX/ is less than 255 and
    the implementation-defined value of the expression /(char) 0xFF/
    is not equal to /254-UCHAR_MAX/).

----------------------------------------------------------------------
Public Comment Number PC-UK0015
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-30
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 5.2.4.2.1

Title: ensure int can hold all characters and EOF

Detailed description:

To eliminate a pathological case, append to 5.2.4.2.1p2:

    On a hosted implementation, INT_MAX shall be not less than UCHAR_MAX.

----------------------------------------------------------------------
Public Comment Number PC-UK0016
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1997-12-30
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.1.1

Title: eliminate conditional keywords

Detailed description:

6.1.1 makes the keywords "complex" and "imaginary" only be "reserved" if
the header <complex.h> is included. This is a problem for two different
reasons.

Firstly, cautious programmers will assume that the keywords might be needed
at some later date, for example by a system header that they have no control
over. Therefore they will have to play safe and not use them. The less
cautious may use them, and then be burnt later when such a change outside
their control happens. Both cases bring the Standard into disrepute.

Seeing that the decision has already been made to introduce new keywords,
there is little benefit in this approach unless it is going to be more
radical (for example, making complex types be unavailable on freestanding
implementations). And, even so, there are better approaches.

Secondly, the term "reserved" is being misused. This term (see 7.1.3)
means that an identifier may not be redeclared. Keywords are not
identifiers, and thus reservation is nonsense. In any case, the syntax
does not allow a keyword to be used as if it were an identifier.

Three alternatives are given here; my preference is for the third.


Alternative 1: delete 6.1.1 paragraph 2.


Alternative 2: if it is still viewed as desirable to make the names
"complex" and "imaginary" available to programmers not using <complex.h>,
then:

* Change the keywords in 6.1.1 to __complex and __imaginary.
* Add to 7.8 a new paragraph 4:

    The macro /complex/ is defined to be /__complex/. If and only if the
    macro /_Imaginary_I/ is defined, then the macro /imaginary/ is defined
    to be /__imaginary/. Notwithstanding the provisions of subclause 7.1.3,
    it is permitted to undefine the macros /complex/ and /imaginary/.


Alternative 3: since complex types are basic to the language while
imaginary types are an extension:

* Change the keyword imaginary in 6.1.1 to __imaginary.
* Add to 7.8 a new paragraph 4:

    If and only if the macro /_Imaginary_I/ is defined, then the macro
    /imaginary/ is defined to be /__imaginary/. Notwithstanding the
    provisions of subclause 7.1.3, it is permitted to undefine the
    macro /imaginary/.

----------------------------------------------------------------------
Public Comment Number PC-UK0017
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-17
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 6.3.9

Title: fix pointer comparison

Detailed description:

DR 172 addressed a number of defects in the rules for pointer comparison,
and the DR authors suggested new wording to fix this. This issue was also
raised in WG14 papers N720 and N783. Following other changes in the
Standard, this wording is no longer completely acceptable. Instead,
replace 6.3.9 paragraphs 3 to 5 with the following text.

    The == (equal to) and != (not equal to) operators are analogous to
    the relational operators except for their lower precedence.[78]
    They yield 1 if the specified relation is true and 0 if it is false.
    The result has type /int/. For any pair of operands, one operator
    shall be true and the other false.

    If both of the operands have arithmetic type, the usual arithmetic
    conversions are performed. [[Insert the existing paragraph 5 here.]]
    Otherwise the operands are pointers; if one is a pointer to an object
    or incomplete type and the other has type pointer to a qualified or
    unqualified version of /void/, the former is converted to the type of
    the latter.

    Two pointers shall compare equal if both are null pointers, both are
    pointers to the same object (including a pointer to an object and a
    subobject at its beginning), the same element of an array object, or
    the same function, if both are pointers to one past the end of the
    same array object, or if one is a pointer to one past the end of one
    array object and the other is a pointer to the start of a different
    array object that happens to be immediately after it in the address
    space.[79] Otherwise they shall compare unequal.

Prepend to footnote 79:

    Two objects may be adjacent in memory because they are adjacent elements
    of some larger array object, because they are adjacent members of a
    structure with no padding between them, or because they are unrelated
    and the implementation chooses to place them adjacent in memory.

----------------------------------------------------------------------
Public Comment Number PC-UK0018
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-04
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.2.7, 6.3.1.1

Title: merge predefined identifiers into one place

Detailed description:

The concept of predefined identifiers is found in two separate places:
6.1.2.7 and 6.3.1.1. The latter location is, I believe, historical cruft
from when __func__ was treated as a special entity. It would read better
to merge the two sections into one, and 6.1.2.7 is a better location.

Delete subclause 6.3.1.1. Replace subclause 6.1.2.7 by the following:

    6.1.2.7 Predefined identifiers

    The identifiers described in the following subclauses shall be
    implicitly defined by the implementation.

    6.1.2.7.1 The identifier __func__

    [[Insert the body of the present 6.3.1.1 here.]]

----------------------------------------------------------------------
Public Comment Number PC-UK0019
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-06
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Request for information/clarification
Committee Draft subsection: 5.1.1.2, 6.3.1.1

Title: handling of characters not in the execution character set

Detailed description:

Consider the code extract:

    char *s = "\u30CE";

During translation phase 5 the universal character name is converted to a
multibyte character. However, it is not stated what happens if the
implementation does not have a representation for Katakana (30CE is within
the Katakana range of annex I). Therefore it is implicitly undefined.

Now consider the following translation unit:

    #include <stdio.h>

    void fff (void);
    void \u30CE (void);

    int main (void)
    {
        fff ();
        \u30CE ();
        return 0;
    }

    void fff (void)
    {
        printf ("This is %s\n", __func__);

    }

    void \u30CE (void)
    {
        printf ("Hello world!\n");
    }

This is clearly strictly conforming (unless I've made an error :-).

Now consider the trivial change:

    #include <stdio.h>

    void fff (void);
    void \u30CE (void);

    int main (void)
    {
        fff ();
        \u30CE ();
        return 0;
    }

    void fff (void)
    {
        printf ("Hello world!\n");
    }

    void \u30CE (void)
    {
        printf ("This is %s\n", __func__);
    }

This is now undefined on any implementation that cannot represent the
Katakana character set ! I have trouble believing that this was intended,
and I certainly feel that, if it is retained, it should be flagged in the
text of the Standard.

----------------------------------------------------------------------
Public Comment Number PC-UK0020
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 4

Title: Adjust wording of footnote 2

Detailed description:

Footnote 2 is not particularly clear. Better wording would be:

    A strictly conforming program can use conditional features, such as
    those in annex F, provided that the use is guarded by an #ifdef
    directive with the appropriate macro. For example:
    [[followed by the existing example]]

----------------------------------------------------------------------
Public Comment Number PC-UK0021
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 4

Title: Further requirements on the conformance documentation

Detailed description:

There are many things that the Standard requires to be documented, but not
all of them are listed in 4p4. Change it to:

    An implementation shall be accompanied by a document that describes
    all features that this International Standard requires to be described
    by the implementation, including all implementation-defined
    characteristics and all extensions.

----------------------------------------------------------------------
Public Comment Number PC-UK0022
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 5.1.1.2

Title: Translation phase 6 is inconsistent

Detailed description:

Change TP 6 in 5.1.1.2p1 to read:

    Adjacent character string literal tokens and wide string literal
    tokens are concatenated.

----------------------------------------------------------------------
Public Comment Number PC-UK0023
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.5.2.1, 6.5.6

Title: Removing implicit int, further lacunae

Detailed description:

The requirement for a type specifier has been omitted from 6.5.2.1 and
6.5.6. In each case, add a constraint:

    At least one type specifier shall be given in each
    specifier-qualifier-list.

----------------------------------------------------------------------
Public Comment Number PC-UK0024
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.2.5

Title: Replace footnote 25

Detailed description:

Footnote 25 is unclear in context. A better description of the situation
is in footnote 29. Replace the text of FN25 with that of FN29, and change
all references to the latter to be references to the former.

----------------------------------------------------------------------
Public Comment Number PC-UK0025
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.3.2

Title: clarify the explanation of the types of an integer constant

Detailed description:

6.1.3.2p5 is rather difficult to read. Better would be to replace it with
a table, like this:

    The type of an integer constant is the first one marked with an X in
    the corresponding column of the table in which its value can be
    represented:

    Suffix:              -   -   U   L   L   LU  LL  LL  LLU
    Base:                D   O/H -   D   O/H -   D   O/H -

    signed int           X   X
    unsigned int             X   X
    signed long          X   X       X   X
    unsigned long            X   X       X   X
    signed long long     X   X       X   X       X   X
    unsigned long long       X   X       X   X       X   X
    /signed extended/    X           X           X
    /unsigned extended/          X           X           X
    /any extended/           X           X           X

    Notes: suffixes may be in either case, and where there are two
    suffixes, in either order.
      D   = decimal
      O/H = octal or hexadecimal

    If an integer constant cannot be represented by any standard type in
    its list, it may be represented by an extended integer type if there is
    one that can represent that value. The type must be signed or unsigned
    if so indicated.

Alternatively, the ad hoc nature of the present description could be
replaced by one more structured:

    The type of an integer constant is the first one in the following list
    in which its value can be represented:
        /signed int/, /unsigned int/,
        /signed long int/, /unsigned long int/,
        /signed long long int/, /unsigned long long int/
    and subject to the following restrictions:
    - if suffixed by /u/ or /U/, then omit the signed types
    - if decimal and not suffixed by /u/ or /U/, then omit the unsigned
      types
    - if suffixed by /l/ or /L/, then omit the first pair
    - if suffixed by /ll/ or /LL/, then omit the first two pairs
    If an integer constant cannot be represented by any of the types
    permitted by the above, it may be represented by an extended integer
    type if there is one that can represent that value and which has the
    same signedness as at least one of the permitted standard types.

----------------------------------------------------------------------
Public Comment Number PC-UK0026
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.4

Title: improve the example of character string literals

Detailed description:

Append to 6.1.4p7, the example:

    When this is used to initialize a static array, the array has three
    members that are initialized to /18/, the value of /'3'/, and /0/
    respectively.

----------------------------------------------------------------------
Public Comment Number PC-UK0027
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 5.1.1.2, 5.2.1, 5.2.1.2, 6.1.2, 6.1.2.5, 6.8

Title: inconsistencies in use of "basic" and "extended" character sets
       and in their relationship to UCNs

Detailed description:

The Standard uses the terms "basic character set" and "extended character
set" at various places. However, the exact meaning of these two is not
clear, and this leads to confusion.

Consider the UTF-8 encoding (codes from 0 to 127 are single byte, codes
from 128 to 255 form part of multibyte characters with length from 2 to 5
bytes). There are five possible execution character sets:

[1] The 95 characters required by 5.2.1p3, plus the null character.
[2] The 128 single byte characters.
[3] The 2**31 multibyte characters.
[4] Set [3] minus set [1].
[5] Set [3] minus set [2].

(and corresponding source sets).

It is unclear whether the "basic character set" means [1] or [2]. The use
of the wording "at least the following members" in 5.2.1p3 implies that
the basic set can be larger than [1]. On the other hand, if the term is
taken to represent [2], then 5.1.1.2p2 would forbid using \u0040 to
represent the @ sign, something which I do not believe was intended, since
it means that the \u form would be forbidden for *all* characters in the
implementation-defined "basic" set.

Consideration of this and related matters has led me to believe that it
is most useful to have terms for [1] and for [4], while on the other hand
there is little or no need to refer to [2], [3], and [5]. Therefore
"basic character set" should represent [1] and "extended character set"
should represent [4]. To do this requires a number of changes.


Replace 5.2.1p1, second sentence, by:

    Each set is further divided into a /basic/ set, whose contents are
    given by this subclause, and an /extended/ set, consisting of zero
    or more locale-specific members (which are not members of the basic
    set).

In 5.2.1p3, delete "at least" in the first sentence, and in the fourth
sentence change "In the execution character set" to "In the basic
execution character set".


Delete the last sentence of 5.2.1p3 ("If any other characters ... the
behavior is undefined"). It is useless for several reasons:
- If translation phase 1 is taken literally, all members of the extended
  character set are replaced by UCNs, which consist of members of the
  basic character set (this point is further addressed below). While some
  are converted back in translation phase 5, all such characters are
  included in the exemptions.
- It does not allow for UCNs in identifiers.
- If such a character was encountered, the preprocessing token it is in
  is either not converted to a token (in which case the sentence does
  not apply) or *is* converted; in the latter case, the constraint of
  6.1p2 is violated and this sentence has no effect.


Delete 5.1.1.2p2, and replace it by a constraint at the end of 5.2.1
(forming a new paragraph 6):

    Constraint

    A universal-character-name shall not specify (in either form) a
    character short identifier less than 00A0 other than the following:
        0024  0040  0060

This is a more consistent position for the restriction, and it has the
useful side effect of making it clear what the UCNs of the basic character
set *are*.


Replace 5.2.1.2p1, first bullet, by:

    - The basic character set shall be present and shall be encoded
      using single-byte characters.


There is no longer a need to check for the shift states of comments, string
literals, and so on, because during translation phase 1 these will have
been converted to a stateless representation using UCNs. Therefore replace
5.2.1.2p2 by:

    If a source file does not consist of a valid sequence of multibyte
    characters, the behavior is undefined.


In 6.1.2.5p2, replace "required source character set enumerated in 5.1.2"
with "basic execution character set" (note that the execution set is more
sensible in this context than the source set).


The second sentence of 6.1.2p2 restricts UCNs in identifiers to those listed
in annex H. If some other UCN appears, it is unclear whether the behavior
is undefined, or whether the UCN is not part of the identifier.

This is further complicated by the example in footnote 122. If the text
appeared in a source file, by translation phase 4 it would be processed
as:

    #define THIS\u0024AND\u0024THAT(a,b) ((a)+(b))

and so the replacement list *does* begin with a character required by
subclause 5.2.1, and thus this is unambiguously a definition of the
object-like macro THIS. However, this completely wrecks the whole point
of 6.8p4 and FN122 (added in TC1).

Replace the second sentence of 6.1.2p2 with:

    Only universal-character-names corresponding to the characters listed
    in annex I are nondigits.[20]

and append to footnote 20:

    Since 00A0 is not listed in annex I, but 00C0 is, the sequence of
    characters a\u00C0b\u00A0 consists of two preprocessing tokens; the
    first is an identifier made up of three nondigits.

(note also the correction to the annex cited).

Replace 6.8p4 by:

    In the definition of an object-like macro, either the replacement list
    shall be separated from the identifier by white space, or it shall
    begin with one of the 26 graphic characters in the basic character set
    other than ( _ or \ (and thus shall not begin with a universal-
    character-name).[122]


Addendum
--------

I have received a comment pointing out that "extended" is usually taken
to include the set before extension; that is, the term could be taken to
include the basic character set as well. An alternative term such as
"supplementary" could be used instead.

----------------------------------------------------------------------
Public Comment Number PC-UK0028
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 5.2.4.1

Title: clarify translation limit for identifiers using UCNs.

Detailed description:

In 5.2.4.1, change the relevant translation limits to:

    - 63 significant initial characters in an internal identifier or
      a macro name (a universal-character-name shall count as one)

    - 31 significant initial characters in an external identifier (a
      univeral-character-name shall count as 4 if less than 0000FFFF,
      and 8 otherwise)

or some other wording that reflects the Committee's intent if different.

----------------------------------------------------------------------
Public Comment Number PC-UK0029
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: [one of the following]
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 5.2.4.2.2

Title: clarify rounding to nearest

Detailed description:

In 5.2.4.2.2p5, change the third case:

    1   to nearest

to:

    1   to nearest (if the value to be rounded is exactly between two
        representable values, it is unspecified which is chosen)

----------------------------------------------------------------------
Public Comment Number PC-UK0030
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 5.1.1.2

Title: Require UCNs to appear in translation phase 1

Detailed description:

Currently, a source file can contain:

    \u12\
	34

and it is unclear whether or not this is a universal character name. Add
to the end of 5.1.1.2 translation phase 2:

    If a character sequence that matches the syntax of a universal-
	character-name is produced by such splicing, the behavior is undefined.

It is also unclear whether:

    ??/u1234

is a universal character name or not. I think the current wording allows
it, but a footnote would be a good idea.

----------------------------------------------------------------------
Public Comment Number PC-UK0031
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-03
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to existing feature retaining the original intent
Committee Draft subsection: 7.3.1.9, 7.18.2.1.9

Title: make ispunct() true for basic punctuation characters

Detailed description:

There appears to be no character for which it is required that ispunct()
is true. This is surprising, to say the least, as one would expect that
it is true for characters like '.' and '('.

Replace 7.3.1.9p2 by EITHER:

    The /ispunct/ function tests for any printing character for which
    neither /isspace/ nor /isalnum/ is true.

OR:

    The /ispunct/ function tests for any character that is one of the
    29 graphic characters in the basic execution character set or is
    one of a locale-specific set of printing characters for which neither
    /isspace/ nor /isalnum/ is true. In the "C" locale it returns true
    only for the characters in the basic execution character set.

[These two are not equivalent outside the "C" locale.]



----------------------------------------------------------------------
Public Comment Number PC-UK0032
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-04
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.1.2.1

Title: tidy-up specification of overlapping scopes

Detailed description:

The use of "non-overlapping" in 6.1.2.1p implies that the "scope" of an
identifier excludes any block where the identifier is redeclared. This is
inconsistent with the description of inner and outer scopes in paragraph 3;
the latter is probably preferable.

Change the word "non-overlapping" in paragraph 1 to "different".

----------------------------------------------------------------------
Public Comment Number PC-UK0033
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.2.2

Title: Fix wording relating to "number of arguments"

Detailed description:

6.3.2.2p2 states "the number of arguments shall agree with the number of
parameters". This does not clearly take account of varargs functions.

Change the wording to:

    the number of arguments shall equal or, if the prototype ends
    with an ellipsis (, ...), shall be no less than, the number of
    parameters (excluding any ellipsis).

----------------------------------------------------------------------
Public Comment Number PC-UK0034
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.2.3

Title: Adjust wording concerning qualifiers on structure members

Detailed description:

6.3.2.3p3 reads, in part:

    If the first expression has qualified type, the result has the
    so-qualified version of the type of the designated member.

This should read:

    The result has all the qualifiers of the first expression and those
    of the designated member.

Also add an example:

    In:
        struct s { int i; const int ci; };
        struct s s;
        const struct s cs;
        volatile struct s vs;

    the various members have the types:

        s.i       int
        s.ci      const int
        cs.i      const int
        cs.ci     const int
        vs.i      volatile int
        vs.ci     volatile const int

----------------------------------------------------------------------
Public Comment Number PC-UK0035
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.3.2.4, 6.3.3.1

Title: Allow increment/decrement of complex objects.

Detailed description:

All the operators that can be applied to a real floating object can also be
applied to complex ones, with the sole exception of ++ and --. There is no
obvious reason for this exception (particularly since the ! operator can be
applied).

In 6.3.2.4p1 and 6.3.3.1p1, change "real" to "arithmetic".

----------------------------------------------------------------------
Public Comment Number PC-UK0036
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change where the intent is unclear
Committee Draft subsection: 6.3.16

Title: Define the result of the assignment operator

Detailed description:

6.3.16p3 states:

    An assignment expression has the value of the left operand after the
    assignment, but is not an lvalue.

It is not clear what this means when the left operand is a volatile object
that changes through external causes - it could mean the value stored, or
it could mean the result of reading the object.

Replace these words with the unambiguous:

    The value of the assignment expression is the value stored in the left
    operand, but is not an lvalue.

----------------------------------------------------------------------
Public Comment Number PC-UK0037
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-17
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.4

Title: Constant expression cannot contain the size of a VLA

Detailed description:

6.4 does not require a constraint for "sizeof(v)" where v has variable
length array type. FN83 also fails to notice this case.

Append to 6.4p3:

    Any /sizeof/ operator shall have an operand whose size is defined
    to be constant.

Move the reference to FN83 to the new end of the paragraph, and within the
footnote change:

    not evaluated

to:

    not evaluated when no component of the operand has variable length
    array type

In 6.4p6 remove the words "sizeof expressions ... name of such a type".

----------------------------------------------------------------------
Public Comment Number PC-UK0038
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be removed
Committee Draft subsection: 6.1.8

Title: UCNs should not be permitted in preprocessing numbers

Detailed description:

The syntax in 6.1.8p1 uses "nondigit", which used to represent the 52 letters
plus underscore but now also includes the UCNs in Annex I. I believe this is
a mistake, and the syntax should be adjusted accordingly.

----------------------------------------------------------------------
Public Comment Number PC-UK0039
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 6.1.3.1

Title: Allow 'i' suffix for floating constants

Detailed description:

It should be possible to write an imaginary floating point constant rather
than having to multiply by the macro /I/. Furthermore, this macro is not
available in a free-standing implementation.

The obvious way to do this is to allow the suffix 'i' or 'I'. To do so:

In 6.1.3.1p1:

- Remove "floating-suffix/opt" from the various alternatives to
  "decimal-floating-constant" and "hexadecimal-floating-constant".
- Append "floating-suffices/opt" to each alternative for
  "floating-constant".
- Add:

    floating-suffices:
        floating-suffix imaginary-suffix
        imaginary-suffix floating-suffix

    imaginary-suffix: one of
        i  I

Append to 6.1.3.1p4:

    If the constant has the suffix /i/ or /I/, then its type and value
    are that resulting when the constant without that suffix is multiplied
    by the value of the macro /I/ defined in the header <complex.h>

and add a forward reference to 7.8.

----------------------------------------------------------------------
Public Comment Number PC-UK0040
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.5.2.1

Title: Bitfields of non-standard types should require a diagnostic.

Detailed description:

If a bitfield is declared with a type other than plain, signed, or unsigned
int, the behavior is undefined. Since this can easily be determined at
compile time, it should generate a diagnostic. An exception is required for
the type underlying /bool/, and perhaps for any type that can have valid
bitfields.

Delete the first sentence of 6.5.2.1p8.

Add to the end of 6.5.2.1p3:

    A bit-field shall have a type that is a qualified or unqualified
    version of /signed int/ or /unsigned int/, or of the type /bool/
    defined in the header <stdbool.h>.

or:

    A bit-field shall have a type that is a qualified or unqualified
    version of /signed int/ or /unsigned int/, of the type /bool/
    defined in the header <stdbool.h>, or of some other implementation-
    defined integer type.

----------------------------------------------------------------------
Public Comment Number PC-UK0041
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.5.2.2, 6.5.2.3

Title: An example uses an incomplete type in the wrong context

Detailed description:

6.5.2.3 example 3 uses the line:

    enum f { c = sizeof (enum f) };

but 6.5.2.2p5 indicates that the type is not complete at the point it is
used in the constant expression, and so a constraint is violated. The
example must be reworded or deleted.

----------------------------------------------------------------------
Public Comment Number PC-UK0042
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-13
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.4

Title: Clarify some aspects of inline

Detailed description:

In 6.5.4p6, add a footnote referenced at the end of the paragraph:

    [*] The call need not be due to the direct appearance of the name of
    the function at the point of calling; it may be through some kind of
    indirection.

In 6.5.4p8, after:

    because /fahr/ is also declared with /extern/

add:

    (even though that declaration is not visible at the definition of
    /fahr/)

----------------------------------------------------------------------
Public Comment Number PC-UK0043
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-14
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.5.7

Title: Clarify when VLA sizes are determined

Detailed description:

6.5.7p3 reads in part:

    Any array size expression associated with variable length array
    declarators shall be evaluated with the typedef name at the beginning
    of its scope upon each normal entry to the block.

This wording appears to say that VLA typedefs are evaluated when the block
containing them is entered, even though this is not the case for any other
kind of declaration (including VLAs themselves). For example:

    {
        int n;
        n = 5;
        int v1 [n];
        n += 2;
        typedef int vec [n];
        n += 2;
        vec v2;
        /* ... */
    }

The above wording would imply that vec, and so v2, contains either 5 or an
undefined number of elements, rather than 7 that the average programmer
would expect.

Change the wording to:

    Any array size expression associated with variable length array
    declarators shall be evaluated with the typedef name at the beginning
    of its scope, and the resulting size shall be used whenever the typedef
    name is subsequently used.

----------------------------------------------------------------------
Public Comment Number PC-UK0044
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-14
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.5.7

Title: Removal of implicit int - further lacunae

Detailed description:

In 6.5.7p3, the last sentence:

    If the identifier is redeclared in an inner scope or is declared as
    a member of a structure or union in the same or an inner scope, the
    type specifiers shall not be omitted in the inner declaration.

are no longer needed, as the type specifiers cannot be omitted.

----------------------------------------------------------------------
Public Comment Number PC-UK0045
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-14
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to feature
Committee Draft subsection: 6.1.2.4, 6.6.4.2, 6.6.6.1

Title: Fix semantics of jumps in relation to VLAs

Detailed description:

Consider the code:

    {
        int n = 1;

    label:
        int v [n];
        /* ... */
        if (n++ < 10)
            goto label;
    }

The constraint on 6.6.6.1 does not forbid this jump, but the storage for
v cannot be allocated on block entry as described in 6.1.2.4p3.

Consider the code:

    {
        int n = 1;
        goto label;

        int v [n];
    label:
        /* ... */
    }

This also does not violate the constraint, but the size of the array is
never determined.

Consider the code:

    int n;
    /* ... */
    if (n > 0)
        goto label;
    {
        n = 1;
    label:
        int v [n];
        /* ... */
    }

This is forbidden by 6.6.6.1, but its meaning is clear and sensible.

The intent of the constraint in 6.6.6.1 is clearly to prevent a jump into
a block from skipping a VLA declaration, but as can be seen it does not
have this effect in practice.

Similarly, the wording of 6.1.2.4p3 for VLAs is obviously an attempt to
adapt the previous wording, but it does not have the right effect.


Previous discussion within WG14 appeared to reach the conclusion that:
- jumping into the scope of a VLA should violate a constraint;
- jumping out of the scope of a VLA causes storage to no longer be
  reserved, even if the block containing the declaration has not been left;
and these rules seem eminently practical. To do this:

In 6.1.2.4p3, replace:

    Storage is guaranteed [...] execution of the block ends in any way.

with:

    For objects that do not have a variable length array type, storage is
    guaranteed to be reserved for a new instance of such an object on each
    entry into the block with which it is associated; the object initially
    has indeterminate value. If an initialization is specified for the
    value stored in each object, it is performed each time the declaration
    is reached in the execution of the program; otherwise the value becomes
    indeterminate each time the declaration is reached. Storage for the
    object is no longer guaranteed to be reserved when execution of the
    block ends in any way. For objects that have a variable length array
    type, storage is guaranteed to be reserved for a new instance of such
    an object each time the declaration is reached in the execution of the
    program. If there is an initializer, it is performed at that point;
    otherwise the initial value is indeterminate. Storage for the object
    is no longer guaranteed to be reserved when execution of the program
    leaves the scope of the declaration [*].

    [*] Leaving the innermost block containing the declaration, or jumping
    to a point in that block or an embedded block before the declaration,
    leaves the scope of the declaration.

In 6.6.4.2p1, replace the first sentence with:

    The controlling expression of a /switch/ statement shall have integer
    type. If the /switch/ statement causes a jump to within the scope of
    an identifier with variably modified type, the entire /switch/ statement
    shall be within the scope of that identifier [*].

    [*] That is, the declaration either preceeds the /switch/ statement,
    or it occurs after the last /case/ or /default/ label that is in the
    block containing the declaration and is associated with the /switch/.

In 6.6.6.1p1, replace the second sentence with:

    A /goto/ statement shall not jump from outside the scope of an
    identifier with variably modified type to inside the scope of that
    identifier.

----------------------------------------------------------------------
Public Comment Number PC-UK0046
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-14
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.7

Title: Correct ranges of bitfields in an example

Detailed description:

In 6.5.7 example 3, change the specified ranges:

- from "at least the range [-15, +15]"
  to "either the range [-15, +15] or the range [-16, 15]"
- from "values in the range [0, 31] or values in at least the range
  [-15, +15]"
  to "values in one of the ranges [0, 31], [-15, +15], or [-16, +15]"

----------------------------------------------------------------------
Public Comment Number PC-UK0047
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-14
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Request for information/clarification
Committee Draft subsection: 6.8

Title: Handling of unknown preprocessing directives

Detailed description:

In the preprocessing phase (translation phase 4), consider the line:

    # unknown command

It is unclear whether or not this requires a diagnostic. Presumably the
# punctuator will remain until translation phase 7 where it cannot fit in
the syntax, but even if so, this is less than clear. However, this is
easy to fix. In the syntax in 6.8p1, change group-part to:

    group-part:
        non-directive new-line
        if-section
        control-line

and add:

    non-directive:
        pp-tokens/opt

Then add a constraints clause:

    Constraint

    The first preprocessing-token (if any) in a non-directive shall not
    be /#/.

Finally, delete 6.8.3p8, because this can no longer occur.

----------------------------------------------------------------------
Public Comment Number PC-UK0048
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-14
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
? Category: Other: unresolved issue
Committee Draft subsection: 6.1.7, 6.8.2

Title: Problems with UCNs in header file names

Detailed description:

Consider the line:

    #include "a$b.h"

This will be changed, in translation phase 1, to:

    #include "a\u0024b.h"

Both of these involve undefined behavior, but equally both are valid file
names on at least one common operating system. It is likely that
implementations that implement UCNs in a natural manner are going to
have problems deciding which of the names was intended.

I'm not clear what the answer is, but it needs addressing.

----------------------------------------------------------------------
Public Comment Number PC-UK0049
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-14
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Request for information/clarification
Committee Draft subsection: 6.8.1

Title: Handling of UCNs in character constants in #if directives

Detailed description:

Consider the line:

    #if '\u0024' < 100

where dollar is in the single-byte execution character set. It is not
completely clear from 6.8.1p3 that the UCN is converted to a single
character, since this normally happens in translation phase 5.

In 6.8.1p3, last two lines of page 157 (postscript version), change:

    ... which may involve converting escape sequences into execution
    character set members. Whether ...

to:

    ... which may involve converting source character set members,
    escape sequences, and universal character names into execution
    character set members in the manner of translation phase 5. However,
    whether ...

----------------------------------------------------------------------
Public Comment Number PC-UK0050
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-14
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.1.2.8.1, 6.3.2.3

Title: Effects on other members of assigning to a union member

Detailed description:

6.3.2.3p5 has wording concerning the storing of values into a union member:

    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.

The requirement to be implementation-defined means that an implementation
must ensure that all stored values are not trap representations in the
types of other members, and thus, in effect, eliminates the possibility of
trap representations at all.

It turns out that the wording of 6.1.2.8.1 is sufficient to explain the
behavior in these circumstances, and the cited wording in 6.3.2.3 merely
muddles the issue. It should be removed; the rest of the paragraph can
stand alone.

----------------------------------------------------------------------
Public Comment Number PC-UK0051
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-16
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 7.1.7

Title: true and false are not reserved identifiers

Detailed description:

7.1.7p3 defines "true" and "false" as macros, which thus reserves them in
accordance with the third bullet of 7.1.3. FN138 suggests that an
implementation could use these names as enumeration constants, but they
are not reserved in that context. That is:

    #include <stdbool.h>
    #undef true;
    complex long double true;

is strictly conforming.

Since the implementation in the footnote is a useful one (for the reasons
given), 7.1.7 should reserve these names at file scope, either explicitly
or by changing these two identifiers to be "const int" (though of course
this would give them an address).

----------------------------------------------------------------------
Public Comment Number PC-UK0052
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-16
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 6.8.3

Title: Add a __VA_COUNT__ facility for varargs macros

Detailed description:

Unlike with function calls, it is trivial for an implementation to
determine the number of arguments that match the ... in a varargs macro.
There are a number of useful things that can be done with this (at the
least, providing argument counts to varargs functions). Therefore this
information should be made available to the macro expansion.

In 6.8.3p5, change
    The identifier /__VA_ARGS__/ ...
to:
    The identifiers /__VA_ARGS__/ and /__VA_COUNT__/ ...

Append to 6.8.3.1p2:

    The identifier /__VA_COUNT__/ that occurs in the replacement list
    shall be treated as if it were a parameter; it is replaced by a
    single token which is the number of trailing arguments (as a decimal
    constant) that were merged to form the variable arguments.

----------------------------------------------------------------------
Public Comment Number PC-UK0053
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-17
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 7.4

Title: Require consistency if an implementation adds to <inttypes.h>

Detailed description:

7.20.3 reserves all names such as int11_t and uint_least22_t. This allows
implementations to define them in <inttypes.h>, but does not require these
names to be handled consistently. Adding such a requirement would aid
portability. This proposal does not require any types other than those
already required by the header.

[The following is a minimal change. If requested, I can rewrite the header
to integrate the changes better.]

Append to 7.4 as a new paragraph 5:

    For each typedef name listed as /optional/ and which can be defined
    as a type existing in the implementation, it is unspecified whether
    or not the type is defined, but if it is provided, so shall the
    corresponding limit and /fprintf/ macros (as with all the types in
    this header, the /fscanf/ macros are optional).

Append to 7.4.1.1, 7.4.1.2, and 7.4.1.3 as a new paragraph 4:

    Any other typedef name of these two forms is an optional type.

Append to 7.4.2 as a new paragraph 3:

    Any optional types shall have /MAX/ and, if signed, /MIN/ macros
    with the appropriate name and value as if explicitly included in
    the following subclauses. For example, if the type /uint14_t/ is
    provided, then the macro UINT14_MAX shall be provided with value
    exactly 16383.

Append to 7.4.4p1:

    Any optional types shall have /fprintf/ and /fscanf/ macros
    with the appropriate name and value as if explicitly included in
    the following lists. For example, if the type /uint14_t/ is
    provided, then the macros /PRIo14/, /PRIu14/, /PRIx14/, /PRIX14/,
    /SCNo14/, /SCNu14/, and /SCNx14/ should be added to the lists below.

----------------------------------------------------------------------
Public Comment Number PC-UK0054
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-17
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Other: C++ conflict avoidance
Committee Draft subsection: 6.8.8

Title: Require that __cplusplus not be defined

Detailed description:

Add to 6.8.8 a new paragraph 5:

The implementation shall not predefine the macro /__cplusplus/, nor shall
it define this macro in any header defined in clause 7.

----------------------------------------------------------------------
Public Comment Number PC-UK0055
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-19
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.8

Title: It should be explicitly possible to redefine I

Detailed description:

7.8p3 should end:

    Not withstanding the provisions of subclause 7.1.3, it is permitted
    to undefine and redefine the macro I.

This was clearly the intent.

----------------------------------------------------------------------
Public Comment Number PC-UK0056
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-19
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 7.1.6

Title: Add a symbol giving the maximum alignment

Detailed description:

[I eventually decided <stddef.h> is the right place for this.]

Add a new macro to <stddef.h>:

    _ALIGNMENT_ALL

    which expands to an integer constant expression that has type /size_t/,
    the value of which is the least common multiple of the alignments of
    all object types.[*]

    [*] If /p/ has pointer to character type and is suitably aligned for
    some type /t/, then /(p + _ALIGNMENT_ALL)/ is also suitably aligned
    for the same type /t/, no matter what /t/ is.

Possibly also add the macros:

    _ALIGNMENT_INTS
    _ALIGNMENT_FLOATS
    _ALIGNMENT_POINTERS

which are the least common multiples of the alignments for integer types,
for floating types, and for pointer types respectively. Other names could
also be conceived of (_ALIGNMENT_STRUCTS, _ALIGNMENT_UNIONS,
_ALIGNMENT_SCALARS, etc.).

----------------------------------------------------------------------
Public Comment Number PC-UK0057
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-19
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.13.2, 7.13.3, 7.19.3.10, 7.19.7

Title: Better locale handling for wide oriented streams

Detailed description:

7.13.2p6 associates an /mbstate_t/ object with each stream, and 7.13.3p11-13
state that this is used with the various wide-oriented functions. On the
other hand, 7.19.7p3 places very strict restrictions on the use of such
objects, restrictions that cannot be met through the functions provided in
the Standard while allowing convenient use of wide formatted I/O.

Furthermore, an /mbstate_t/ object is tied to a single locale based on the
first time it is used. This means that a wide oriented stream is tied to
the locale in use the first time it is read or written. This will be
surprising to many users of the Standard.

Therefore, at the very least these objects should be exempt from the
restrictions of 7.19.7; the restrictions of 7.13 (for example, 7.13.2p5
bullet 2) are sufficient to prevent unreasonable behaviour. In addition,
the locale of the object should be tied and not affected by the current
locale. The most sensible way to do this is to use the locale in effect
when the file is opened, but allow /fwide/ to override this.

In 7.13.2p6, add after the first sentence:

    This object is not subject to the restrictions on direction of use
    and of locale that are given in subclause 7.19.7. All conversions
    using this object shall take place as if the /LC_CTYPE/ category
    setting of the current locale is the setting that was in effect when
    the orientation of the stream was set with the /fwide/ function or,
    if this has not been used, when the stream was opened with the
    /fopen/ or /freopen/ function.

In 7.19.3.10, add a new paragraph after paragraph 2:

    If the stream is successfully made wide oriented, the /LC_CTYPE/
    category that is used with the /mbstate_t/ object associated with
    the stream shall be set to that of the current locale.

In 7.19.7p3, append:

    These restrictions do not apply to the /mbstate_t/ objects associated
    with streams.

----------------------------------------------------------------------
Public Comment Number PC-UK0058
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Request for information/clarification
Committee Draft subsection: 7.13.4.3

Title: Unclear how many times tmpfile() can be called.

Detailed description:

Nowhere does the Standard state how many times tmpfile() can be called, nor
does it state that several successful calls will actually access different
files !

Append to 7.13.4.3p2:

    The file will be different from any other existing file, including any
    opened by a previous successful call to the /tmpfile/ function.

Add a new part to 7.13.4.3:

    Recommended practice

    It should be possible to open at least /TMP_MAX/ temporary files
    during the lifetime of the program, and no limit on the number
    simultaneously open other than this limit and any limit on the
    number of open streams (FOPEN_MAX). The limit of /TMP_MAX/ could be
    shared with calls to /tmpnam/.

----------------------------------------------------------------------
Public Comment Number PC-UK0059
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-19
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.8

Title: Add a description of the start symbol to the preprocessing grammar

Detailed description:

There is (still) no clear description of the grammar that a preprocessing
file needs to obey. That is, the grammar is there but its applicability is
not given.

Add a new paragraph to 6.8 just before paragraph 5:

    As discussed in 5.1.1.1, the unit of program text before preprocessing
    (at the start of translation phase 4) is a preprocessing file. As shown
    in the grammar above, this consists of a sequence of conditional
    inclusion blocks, other preprocessing directives, and other text.

----------------------------------------------------------------------
Public Comment Number PC-UK0060
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-19
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 7.2

Title: Clarify multiple insertions of <assert.h>

Detailed description:

The rules for including <assert.h> are partly in 7.1.2 and partly unstated.
They should be stated more clearly in 7.2. Add to the end of 7.2p1:

    The /assert/ macro is redefined according to the current state of
    /NDEBUG/ each time that /<assert.h>/ is included.

----------------------------------------------------------------------
Public Comment Number PC-UK0061
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-19
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.2.1

Title: Explicitly allow assert on non-integer arguments

Detailed description:

A DR response stated that assert need not correctly handle arguments
which are not of type int but can be compared with zero. At the very
least, this forbids arguments which are unsigned int or long, let alone
other scalar types. Since it is trivial to have the macro convert any
scalar to truth value integer by prefixing it with the !! operator, this
restriction should be removed.

In 7.2.1.1p1, change "int expression" to "scalar expression", where the
word "scalar" is in italics. Add to paragraph 2, either after the first
sentence or at the end:

    The argument of the /assert/ macro is any expression with scalar type.

----------------------------------------------------------------------
Public Comment Number PC-UK0062
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-19
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 7.13.3, 7.13.5.4

Title: Provide a way to make the standard streams binary

Detailed description:

7.13.3p7 states that the three standard streams are text. This makes it
impossible to write programs like "cat" on systems where text and binary
streams are not the same.

There are a number of ways to provide this facility. Here is my prefered
one: add a new paragraph to 7.13.5.4 before paragraph 3:

    If /filename/ is a null pointer, the /freopen/ function attempts to
    change the mode of the stream to that specified by /mode/, as if the
    name of the file currently associated with the stream had been used.
    It is implementation-defined which changes of mode (if any) are
    permitted and under what circumstances.

----------------------------------------------------------------------
Public Comment Number PC-UK0063
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-29
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 7.13.9

Title: Provide a way to compare fpos_t values.

Detailed description:

There is no way to determine whether two fpos_t values represent the same
position in a file. Therefore, it is not possible to do operations such as
the following:

- open a file
- move through it, looking for some mark
- note the position using fgetpos()
- rewind
- move through it again to the same position, using calls to fgetpos()
  to determine where you are, rather than relying on having made exactly
  the same sequence of reads and seeks

Add a new function to 7.13.9:

    7.13.9.X The fcmppos function

    Synopsis

        #include <stdio.h>
        struct fcmppos fcmppos (fpos_t* pos1, fpos_t* pos2, FILE *stream)

    Description

    The /fcmppos/ function compares the values pointed to by /pos1/ and
    /pos2/, which must both refer to the stream /stream/. If either of the
    first two arguments is a null pointer, the result of a call to the
    /fgetpos/ function on the stream is used instead. If the stream has
    been written to at any point before the later of the two positions,
    the behaviour is undefined.

    Returns

    The value returned is a structured type containing at least the
    following fields:

        int before;   // Less than, equal to, or greater than zero according
                      // to whether /*pos1/ is before, at the same location
                      // as, or after /*pos2/ in the file.
        int mbstate;  // Zero if and only if the two positions have the same
                      // multibyte parsing status.

It will also be necessary to add /struct fcmppos/ to the start of 7.13.

----------------------------------------------------------------------
Public Comment Number PC-UK0064
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-19
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Request for information/clarification
Committee Draft subsection: 7.13.8.1, 7.13.8.2

Title: Clarify the actions of fread and fwrite

Detailed description:

The exact behaviour of fread and fwrite are not well specified, particularly
on text streams.

In 7.13.8.1p2, add after the first sentence:

    For each object, /size/ calls are made to the /fgetc/ function and
    the results stored, in the order read, in an array of /unsigned char/
    exactly overlaying the object.

In 7.13.8.2p2, add after the first sentence:

    For each object, /size/ calls are made to the /fputc/ function, taking
    the values (in order) from an array of /unsigned char/ exactly
    overlaying the object.

----------------------------------------------------------------------
Public Comment Number PC-UK0065
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-20
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Request for information/clarification
Committee Draft subsection: various

Title: What is the precision of floating point calculations ?

Detailed description:

DR 063 asked, for C89, what was the required precision of the results of
the various floating point operators and functions. To date this has not
been answered. I am not aware enough of the issues to be able to write a
good answer myself, but references to IEC 559 and annex F are not a
sufficient solution.

----------------------------------------------------------------------
Public Comment Number PC-UK0066
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-20
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: various

Title: The term "access" is not well defined.

Detailed description:

The term "access" is not well defined. From context, it sometimes appears
to mean "read the value", and sometimes "read or write the value". This
ambiguity sometimes makes it hard to understand what is actually meant.

There needs to be a definition in clause 3, and all uses of the term
need to be checked for the read-only / read-write problem. Probably the
best approach is to define it as "read or write", and to find and fix
the places where "read" is meant.

An example where "access" clearly means "read" is in 6.5.3.1p5:

    A reference to a value means either an access to or a modification
    of the value.

So "access" presumably means read but not write. But if so, then 6.5.3p6:

    What constitutes an access to an object that has volatile-qualified
    type is implementation-defined.

must also exclude writing. But that would mean that what constitutes a write
to a volatile object is *not* implementation-defined, but rather undefined !
Since this is obviously not the intent, there is a clear contradiction that
needs resolving.

There are plenty of other instances; for example, 6.3p6:

    ... If a value is stored into an object ... the type of the lvalue
    becomes the effective type of the object for that access ...

where writing is clearly meant to be included.

However, the point is not to address these individual cases but rather
make the whole Standard consistent.

----------------------------------------------------------------------
Public Comment Number PC-UK0067
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-21
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Other: tidy up (technically normative)
Committee Draft subsection: 7.14

Title: tidy up definitions of <stdlib.h> macros

Detailed description:

In 7.14p3, change:

        EXIT_SUCCESS

    which expand to integer expressions which ...

to:

        EXIT_SUCCESS

    which expand to integer constant expressions which ...

and change:

        MB_CUR_MAX

    which expands to a positive integer expression whose value
    ... never greater than /MB_LEN_MAX/.

to:

        MB_CUR_MAX

    which expands to a positive integer expression whose type is /size_t/
    and whose value ... never greater than /MB_LEN_MAX/. This is not a
    constant expression: it may change whenever the locale changes.

----------------------------------------------------------------------
Public Comment Number PC-UK0068
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-21
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Other: rewording to show consistency
Committee Draft subsection: 7.14.6.2

Title: Change the description of div() to show consistency

Detailed description:

Change the description of the div function (7.14.6.2) to:

    Description

    The /div/ function computes the quotient and remainder of the division
    of the numerator /numer/ by the denominator /denom/.

    Returns

    The /div/ function returns a structure of type /div_t/, comprising
    both the quotient and the remainder. The structure shall contain the
    following members, in either order:

        int quot;    // quotient, equivalent to (numer / denom)
        int rem;     // remainder, equivalent to (numer % denom)

    If either part of the result cannot be represented, the behavior is
    undefined.[*]

    [*] The function is equivalent to:

        div_t div (int numer, int denom)
    	{ return (div_t) { .quot = numer / denom, .rem = numer % denom }; }

Alternatively, simply replace the entire description by the code in the
suggested footnote.

----------------------------------------------------------------------
Public Comment Number PC-UK0069
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-21
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Normative change to intent of existing feature
Committee Draft subsection: Annex G

Title: Reorganise annex G as two separate items

Detailed description:

Annex G currently gives a specification for IEC 559 compatible complex
types *and* for imaginary types, all conflated. These are separate concepts
which can each be useful. Annex G should be split into two separate parts.

The first annex is "Imaginary Types" and is normative. It begins something
like:

    This annex specifies imaginary types. An implementation shall either
    conform to all the requirements of this annex, and shall define the
    macro /_Imaginary_I/ in <complex.h>, or it shall not provide such
    types, shall not define the macro /_Imaginary_I/, and shall not define
    the keyword /imaginary/.

It then includes all the imaginary type parts: G.2, G.3, G.4.1p1-3,
G.4.2 (except for the words "and exceptions"), G.5p1, G.6.

The second annex is "IEC 559 compatible complex arithmetic" and is normative.
It is introduced with words like those in F.1, including:

    An implementation that defines __STD_IEC_559_COMPLEX__ conforms to
    the specification in this annex.

It then includes G.4.1p4-7, G.4.2p2, G.5 except p1.

----------------------------------------------------------------------
Public Comment Number PC-UK0070
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-21
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 7.9

Title: Type-generic macros should be generally useful

Detailed description:

7.9 introduces the concept of type-generic macros, but these are only
available for a small range of mathematical functions. This facility should
be made generally available so that they can be used for general
programming.

----------------------------------------------------------------------
Public Comment Number PC-UK0071
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-21
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Inconsistency
Committee Draft subsection: 6.8.2

Title: Clarify included file process

Detailed description:

6.8.2p3 ends:

    If this search is not supported, or if the search fails, the directive
    is reprocessed as if it read

        #include <h-char-sequence> new-line

    with the identical contained sequence (including > characters, if any)
    from the original directive.

The wording is technically incorrect, precisely because the original
directive could contain angle brackets within the quotes whereas an
h-char-sequence cannot. Better wording would be:

    If this search is not supported, or if the search fails, the directive
    is reprocessed as if it read

        #include <h-char-sequence> new-line

    with the identical contained sequence from the original directive
    (if the q-char-sequence contains a > character, this is retained in
    the name searched for even though it could not appear in a true
    h-char-sequence).

----------------------------------------------------------------------
Public Comment Number PC-UK0072
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-21
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Feature that should be included
Committee Draft subsection: 7.11.1.1, 7.14.4

Title: _exit function

Detailed description:

As part of a working paper (N789), I suggested that C provide an _exit()
function like that in POSIX, and signal handlers should be allowed to
call this function. After further discussion, it would still appear that
this function is useful and can be specified in a way that is completely
conformant to POSIX. However, I have made some improvements to the wording
in N789.

Make the following changes:

In 7.11.1.1 paragraph 5, change:

    or the signal handler calls any function in the standard library
    other than the /abort/ function or the /signal/ function

to:

    or the signal handler calls any function in the standard library
    other than the /abort/ function, the /_exit/ function, or the
    /signal/ function

Add a new subclause 7.14.4.4 within 7.14.4 (Communication with the
environment), renumbering subsequent subclauses.

    7.14.4.4 The _exit function

    Synopsis

    #include <stdlib.h>
    void _exit (int status);

    Description

    The /_exit/ function causes normal program termination to occur,
    and control to be returned to the host environment. No functions
    registered by the /atexit/ function or signal handlers registered by
    the /signal/ function are called. The /_exit/ function never returns
    to the caller. The status returned to the implementation is determined
    in the same manner as for the /exit/ function. It is implementation-
    defined whether open output streams are flushed, open streams closed,
    or temporary files removed.


----------------------------------------------------------------------
Public Comment Number PC-UK0073
ISO/IEC CD 9899 (SC22N2620) Public Comment

=========================================== 

Date: 1998-01-21
Author: Clive D.W. Feather
Author Affiliation: Self
Postal Address:
    Demon Internet Limited
    322 Regents Park Road
    London
    N3  2QQ
    United Kingdom
E-mail Address: <clive@demon.net>
Telephone Number: +44 181 371 1138
Fax Number:       +44 181 371 1037
Number of individual comments: 1


Comment 1. 
Category: Other: clarification
Committee Draft subsection: 6.5.5

Title: clarify order of evaluation of expressions within full declarators

Detailed description:

6.5.5p3 states:

    The end of a full declarator is a sequence point.

However, a full declarator can contain several expressions that require
evaluation, and no ordering is stated. For example:

    int n;
    /* ... */
    int v [++n][++n];

It is not clear whether this is undefined behavior (two modifications to
n), unspecified behavior (which expression is evaluated first), or has a
defined order.

Change the cited wording to:

    The end of a full declarator is a sequence point; the various
    expressions within a full declarator are evaluated using the same
    rules for expression ordering as if they were combined into a single
    expression using the + operator.
------------------------------------------------------------------------
USA Public Comments
------------------------------------------------------------------------
Public Comment Number PC-US0001
------------------------------------------------------------------------

Date:               1998-01-21 (Received 1998-01-23)
Author:             David R. Tribble
Author Affiliation: Self
Postal Address:     6004 Cave River Dr.
                    Plano, TX 75093-6951
                    USA
E-mail Address:     dtribble@technologist.com
                    david.tribble@central.beasys.com
                    dtribble@flash.net
Telephone Number:   +1 972 738 6125, 16:00-00:00 UTC
                    +1 972 964 1729, 01:00-05:00 UTC
Fax Number:         +1 972 738 6111

------------------------------------------------------------------------

Category: Request for clarification

Committee Draft subsection: 6.1.1, 7.8

Title: 'complex' not always a keyword

Detailed description:

Section 6.1.1 states that 'complex' and 'imaginary' are reserved keywords
only if the <complex.h> header has been included by the source program. In
addition, the use of them prior to such an inclusion is deemed undefined.

Why are they not treated as reserved words all of the time?

One possible explanation is that this is an attempt to limit the number of
existing programs that will break with the addition of new keywords.
This, however, seems to be a moot point since the use of either keyword
(without the inclusion of <complex.h>) results in undefined behavior.
Also, this is a weak argument in light of the fact that other new keywords
have been introduced into the language (e.g., 'restrict' and 'inline')
which could break existing programs.

Another possible explanation might be that this is to preserve
compatibility with C++, since C++ uses 'complex' as a template class name
in its standard library.

A clarification of this matter seems to be in order.

An alternative is to require that 'complex' and 'imaginary' are always
reserved words, regardless of the inclusion of <complex.h> or not.

------------------------------------------------------------------------
Public Comment Number PC-US0002
------------------------------------------------------------------------

Date:               1998-01-21 (Received 1998-01-23)
Author:             David R. Tribble
Author Affiliation: Self
Postal Address:     6004 Cave River Dr.
                    Plano, TX 75093-6951
                    USA
E-mail Address:     dtribble@technologist.com
                    david.tribble@central.beasys.com
                    dtribble@flash.net
Telephone Number:   +1 972 738 6125, 16:00-00:00 UTC
                    +1 972 964 1729, 01:00-05:00 UTC
Fax Number:         +1 972 738 6111

------------------------------------------------------------------------

Category: Request for clarification

Committee Draft subsection: 5.1.1.2, 5.2.1, 6.1.2

Title: Source characters not allowed as UCNs

Detailed description:

Section 5.1.1.2 states that UCN codes representing characters in the
source character set are not allowed within the source text.  For example,
the following fragment is illegal:

   int func(int i)
   {
       return \u0030;          // \u0030 is '0'
   }

   int bar(int \u006A)         // \u006A is 'j'
   {
       return \u006A + 1;
   }

But this fragment is legal:

   int foo(int \u00E1)         // \u00E1 is 'a'+accent
   {
       return \u00E1 * 2;
   }

There is little difference in these fragments.  What is the reason for the
limitation on valid UCN codes?

Conceivably, a Unicode text editor might store all the characters in a
file as UCN sequences for maximum portability.  Allowing most characters
to be written as UCNs but requiring a few characters to be written
strictly as 7-bit ISO-646 characters seems like an artificial restriction.

A C compiler implementation could choose to convert all source characters
into 16-bit (or even 32-bit) codes internally, preferring to convert UCNs
into single internal codes as they are read.  Why should it be prevented
from accepting every alphanumeric ISO-10646 character, instead of every
alphanumeric character /except/ 'a'-'z' et al?

------------------------------------------------------------------------
Public Comment Number PC-US0003
------------------------------------------------------------------------

Date:               1998-02-05 (Received 1998-02-06)
Author:             David R. Tribble
Author Affiliation: Self
Postal Address:     6004 Cave River Dr.
                    Plano, TX 75093-6951
                    USA
E-mail Address:     dtribble@technologist.com
                    david.tribble@central.beasys.com
                    dtribble@flash.net
Telephone Number:   +1 972 738 6125, 16:00-00:00 UTC
                    +1 972 964 1729, 01:00-05:00 UTC
Fax Number:         +1 972 738 6111

------------------------------------------------------------------------

Category: Normative change

Committee Draft subsection: 4, 6.8.8, 7.1.3.

Title: Useless __STDC__ macro

Detailed description:

Section 6.8.8 states that the predefined '__STDC__' macro has the value 1,
indicating a conforming implementation.  Section 4 states fairly clearly
just exactly what a "conforming" and a "strictly conforming"
implementation are.  Section 7.1.3 states exactly what a "reserved"
identifier is.

While appealing in theory, the '__STDC__' macro is useless in practice.

Programmers typically test for '__STDC__' in order to ascertain the
answers to the following questions:

   1.  Does the implementation support the standard keywords and syntax
   (such as 'const', 'void *', and prototypes)?

   2.  Does the implementation supply the standard header files (such
   as <stdio.h> and <stdarg.h>)?

   3.  Does the implementation supply the standard library functions
   (such as 'printf' and 'setjmp')?

For example, the following fragment is typical for use with compilers that
support a "compile in non-ISO K&R mode" switch, in order to allow for
correct declarations in both ISO and K&R modes:

   #ifdef __STDC__
   #define P(d)    d
   #else
   #define P(d)    ()
   #endif

   extern int      my_foo P((int arg));
   extern void     my_bar P((const char *n));

While conforming compilers are allowed to have extensions, some compilers
deviate from 7.1.3 by providing keywords that reside in the unreserved
namespace.  For example, Microsoft Visual C provides the 'near' and 'far'
keywords as extensions (for dealing with segmented pointer types on Intel
hardware); as such, it is not conforming and so does not define '__STDC__'
at all, even though it supports the full ISO C syntax and library.  Other
vendors, such as Sun, define '__STDC__' but define it to 0, presumably to
indicate that they support the syntax and library of ISO C but still have
extensions.  Some vendors' compilers have a "ANSI/ISO compliance" switch
that, when enabled, causes '__STDC__' to be defined as 1, but to cause all
nonconforming constructs to be flagged as errors; this is fine in theory,
but in practice it cripples a program, usually by disabling the
declarations for system functions or by flagging such calls as errors.

Unfortunately, 6.8.8 does not define what value '__STDC__' should have in
such near-conforming implementations.

Theoretically, the '__STDC_VERSION__' macro can be tested to determine
what language features are supported.  But there is no guarantee that this
macro will be defined properly by vendors either.  (Indeed, it isn't on
many implementations.)

Proposal:

In order to clarify the issue, in the hopes of providing programmers a
more useful macro, I propose that 6.8.8 be changed to the following:

   __STDC__  The decimal constant 1, indicating a fully conforming
             implementation, or the decimal constant 0, indicating
             a conforming implementation with extensions [note].

   note:  Such extensions would potentially cause some otherwise
          conforming programs to be nonconforming (such as the addition
          of keywords that are not reserved in this standard [7.1.3]).
          Implementations that are not conforming (with or without
          extensions) or that are incapable of translating strictly
          conforming programs shall not define this macro.

(The very last "shall not" phrase might be considered a bit weak, because
it attempts to define what nonconforming compilers cannot do.  Such
compilers, by their very nature, are not likely to abide by anything a
standard has to say.)

------------------------------------------------------------------------
------------------------------------------------------------------------
Public Comment Number PC-US0004
------------------------------------------------------------------------

Date:               1998-02-09
Author:             David R. Tribble
Author Affiliation: Self
Postal Address:     6004 Cave River Dr.
                    Plano, TX 75093-6951
                    USA
E-mail Address:     dtribble@technologist.com
                    david.tribble@central.beasys.com
                    dtribble@flash.net
Telephone Number:   +1 972 738 6125, 16:00-00:00 UTC
                    +1 972 964 1729, 01:00-05:00 UTC
Fax Number:         +1 972 738 6111

------------------------------------------------------------------------

Category: Normative change to existing feature retaining the original
          intent

Committee Draft subsection: 5.1.2.2.1.

Title: Modifiable argv pointers

Detailed description:

 Section 5.1.2.2.1 "Program startup" states that the 'argv' parameter to
 main() and the strings pointed to by the argv array shall be modifiable
 by the program.  However, no mention is made of whether or not the
 pointers themselves shall be modifiable.

 It is my understanding that some systems allow the pointers to be
 modified without ill effects to the program, while other systems do
 not.

Proposal:

 In order to clarify the issue, I propose that the following be appended
 to the last paragraph of [5.1.2.2.1 #2]:

    Whether or not the pointers of the argv array shall be modifiable by
    the program is implementation-defined.  If they are modifiable, they
    shall retain their last-stored values between program startup and
    program termination.

------------------------------------------------------------------------
Public Comment Number PC-US0005
------------------------------------------------------------------------

Date:               1998-02-10 (Received 1998-02-11)
Author:             David R. Tribble
Author Affiliation: Self
Postal Address:     6004 Cave River Dr.
                    Plano, TX 75093-6951
                    USA
E-mail Address:     dtribble@technologist.com
                    david.tribble@central.beasys.com
                    dtribble@flash.net
Telephone Number:   +1 972 738 6125, 16:00-00:00 UTC
                    +1 972 964 1729, 01:00-05:00 UTC
Fax Number:         +1 972 738 6111

------------------------------------------------------------------------

Category: Normative change to existing feature retaining the original
          intent

Committee Draft subsection: 7.1.6.

Title: NULL macro type

Detailed description:

 Section 7.1.6 [#3] states that the standard macro 'NULL' expands to an
 "implementation-defined null pointer constant".

 I feel that the standard ought to restrict the use of the 'NULL' macro
 to pointer expressions only, i.e., make it illegal to use 'NULL' as an
 integer expression.  As defined currently, 'NULL' can be defined as
 '0' or '0L' as well as '((void*)0)'.  The former two are integer
 constants, allowing for the possibility of 'NULL' being used as an
 integer constant on some implementations.  Disallowing 'NULL' as an
 integer constant would make this dubious practice illegal.

Proposal:

 I propose the following change to [7.1.6 #3]:

    [#3]  The macros are

        NULL

    which expands to an implementation-defined null pointer constant of
    pointer type; and ...

 (The rest of the sentence is unchanged.)

Discussion:

 [1]
 The use of 'NULL' as an integer constant is an inappropriate
 programming practice.  Some examples are:

    int     i =  NULL;         // Should be 0
    char    ch = NULL;         // Should be '\0' or NUL
    memset(p, NULL, sz);       // Should be '\0' or 0
    if (ch > NULL) ...         // Should be '\0' or 0

 The 'NULL' macro ought to represent a pointer value, not simply a zero
 value.

 [2]
 Many implementations could define 'NULL' thus:

    #define NULL  ((void*)0)

 which meets the requirements above.  A few implementations use a
 representation other than "all bits zero" to represent a null pointer,
 so they could define 'NULL' as something like this:

    #define NULL  ((void*)0x80000000)    // ala IBM CICS

 The definition above does not restrict the type of 'NULL' to anything
 other than a pointer type; it is not required to be 'void*' per se,
 but could be whatever type the compiler vendor deems appropriate.  For
 example:

    #define NULL  __null           // Vendor A

    #define NULL  ((__notype*)0)   // Vendor B

 In these cases, '__null' and '__notype' are implementation-specific
 reserved words with special meanings.  (It is assumed that in both
 cases the type of 'NULL' is "implementation-specific pointer type".)

------------------------------------------------------------------------
Public Comment Number PC-US0006
------------------------------------------------------------------------

Date:               1998-02-13 (Received 1998-02-13)
Author:             David R. Tribble
Author Affiliation: Self
Postal Address:     6004 Cave River Dr.
                    Plano, TX 75093-6951
                    USA
E-mail Address:     dtribble@technologist.com
                    david.tribble@central.beasys.com
                    dtribble@flash.net
Telephone Number:   +1 972 738 6125, 16:00-00:00 UTC
                    +1 972 964 1729, 01:00-05:00 UTC
Fax Number:         +1 972 738 6111

------------------------------------------------------------------------

Category: Request for clarification

Committee Draft subsection: 5.2.2, 7.3.1.4, 7.3.1.6, 7.3.1.8.

Title: isprint('\t')

Detailed description:

Section 5.2.2 defines the semantics of the standard nongraphic
characters ('\a' through '\v').  Sections 7.3.1.4, 7.3.1.6, and 7.3.1.8
define the iscntrl(), isgraph(), and isprint() library functions.

What is not clear is whether the "nongraphic" characters of 5.2.2 are
printable or not; in particular, is the result of isprint('\t') true or
false?  5.2.2 states that '\t' et al are "nongraphic", which would seem
to imply that isgraph('\t') is false, and by implication, isprint('\t')
is also false.

It is also unspecified whether or not the "nongraphic" characters are
"control characters", i.e., it does not seem clear that iscntrl('\t')
must be true.

Vendors are inconsistent about this.  (Unix vendors, for instance,
usually define isprint('\t')==0, while Microsoft Visual C defines
isprint('\t')!=0.)  Most seem to agree that the "nongraphic" characters
of 5.2.2 are control characters (so that iscntrl('\t') is true).  But
'\t' appears to be a special case; yes, it's a control character, but
is it also a printable character (just like ' ')?

This should be clarified in the standard.  (I personally think that
isprint('\t') should be false; after all, if it's true, shouldn't
isprint('\f') and others also be true?  But I think that would be a
mistake.)

Perhaps the use of the word "nongraphic character" (in 5.2.2) should be
replaced with something more exact, such as "control character".  And
perhaps the definitions of the iscntrl(), isprint(), and isgraph()
functions could be clarified so that it is impossible for some
character code X to be both iscntrl(X)!=0 and isprint(X)!=0, i.e.,
the "control" and "printable" (or "graphic") characters are defined as
mutually exclusive sets.

(As I recall, Clive D. W. feather wrote something on this before, but
apparently it didn't make it into the draft.)
------------------------------------------------------------------------