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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: <[email protected]>
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: [email protected]
[email protected]
[email protected]
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: [email protected]
[email protected]
[email protected]
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: [email protected]
[email protected]
[email protected]
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: [email protected]
[email protected]
[email protected]
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: [email protected]
[email protected]
[email protected]
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: [email protected]
[email protected]
[email protected]
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.)
------------------------------------------------------------------------