ISO/
IEC
JTC1/SC22/WG14
N799
SC22/WG14 N799
Editor's Report
January 2, 1998
1. Status
As you know, an editorial committee consisting primarily of
Benito, Farance, Jaeschke, Jones, MacDonald, and Walls (with
the assistance of Thomas, Gwyn, and others) met in Santa
Cruz November 17-20 to prepare the draft for CD ballot.
After much work at the meeting and some subsequent
formatting clean-up, a final document was prepared on
November 24 and forwarded to SC22. A preliminary version of
this draft was distributed (via the committee's web page) as
N794; this document has been circulated outside the
committee as well as within it and has generated a fair
amount of discussion on the comp.std.c newsgroup as well as
some private e-mail pointing out errors and omissions. The
remainder of this report is based on these comments as well
as my own review.
2. CD1 Errata
General
All of the headings are too small. When the size of the
body text was increased, the sizes of the headings were not
increased to match.
General
None of the tables are properly formatted in the text
version due to a production error.
General
There are many typesetting issues still to be addressed.
For example, there are many equations typeset as code and
vice versa, particularly in annexes F and G. Some of these
issues primarily affect the typeset version and some
primarily affect the text version.
General
The term ``universal-character-name'' should not be
hyphenated (other than in the syntax).
Clause 3, Paragraph 2, Page 3
The reference to ISO 2382-1 should be to ISO/IEC 2382-1.
SC22/WG14 N799 2
5.1.1.2, Forward References, Page 10
There should be a forward reference to 5.2.1 for universal
character names.
5.1.2.3, Example 6, Page 16
``However'' (4th line from the end) should be followed by a
comma.
5.2.1.1, Footnote 12, page 19
The reference to ISO/IEC 646:1991 should be to ISO 646.
5.2.4.2.2, Paragraph 6, Page 26
The list of values should be indented like the one in
paragraph 5.
6.1 and 6.2, Pages 31-66
The reorganization specified in N672 has not been applied.
6.1.2, Paragraph 2, Page 34
The reference to annex H should be to annex I.
6.1.2.5, Footnote 30, Page 40
In the last line, there should not be a comma after ``two''
and ``it'' should be ``is''.
6.1.2.6, Paragraph 1, Page 42
Near the end of the fifth line, the period after ``following
requirements'' should be a colon.
6.1.4, Paragraph 6, Page 55
Although this paragraph doesn't contain the magic word
``unspecified'', whether string literals are distinct or not
is unspecified and should be added to K.1.
6.1.5, Paragraph 1, Page 55
The definition of operator is missing { and }, although it
does have the alternative spellings <: and :>. They
should also appear in the constraint. (Also annex B.)
6.1.6, Paragraph 1, Page 56
The definition of punctuator is missing .. (Also annex B.)
3 SC22/WG14 N799
6.2.1.1, Paragraph 2, Page 60
The period after ``may be used'' should be a colon.
6.2.1.3, Footnote 48, Page 61
In the last line, there should be a space after the comma.
6.3.2.2, Paragraphs 5-6, Page 72
These paragraphs are almost impossible to read correctly.
At the very least, paragraph 6 should be a continuation of
paragraph 5, not a new paragraph. My suggestion is to keep
paragraph 6 and move the end of paragraph 5 starting at the
fifth line (``If the function is defined...'') to the end
of paragraph 6.
6.3.2.5, Example 5, Page 78
In the last line of code, there should be a space before the
square brackets.
6.3.3.3, Paragraphs 2-4, Page 81
In each paragraph, ``the integer promotion is'' should be
``the integer promotions are''.
6.3.6, Paragraph 12, Page 87
In line 2, ``know constant size'' should be ``known constant
size''.
6.3.15, Paragraphs 4-6, Page 93
The last clause of paragraph 4 should read:
the result of the operator is the value of the
second or third operand (whichever is evaluated),
converted to the type described below.
The first sentence of paragraph 5 should read:
If both the second and third operands have
arithmetic type, the type that the usual
arithmetic conversions would yield if applied to
those two operands is the type of the result.
The last sentence of paragraph 6 should read: ``in which
case the type of the result is pointer to void.''
6.5.2, Paragraph 4, Page 103
In the middle of the second line, ``specified'' should be
``specifier''.
SC22/WG14 N799 4
6.5.2.3, Paragraph 3, Page 108
In the second line, ``complete'' should be ``incomplete''.
6.6.4.1, Paragraph 3, Page 142
In the first line, ``preceeding'' should be ``preceding''.
(And I'd be grateful if anyone could explain to me why
ispell doesn't complain about it.)
6.6.6.1, Example 2, Page 146
In the middle of the block of code, the line ``goto lab 4;''
should be ``goto lab4;''.
6.8.8, Paragraph 1, Page 170
It might be clearer to specify that __LINE__ is the line
number within the current source file and that __FILE__ is
the name of the current source file.
6.8.8, Paragraph 2, Page 171
The second line should not appear and the remainder of the
paragraph should be formatted as definitions as in the
previous paragraph.
6.8.9, Paragraph 1, Page 172
In the third line, the period after ``follows'' should be a
colon.
6.8.9, Examples, Paragraph 2, Page 172
In the #pragma, ``list'' should be ``listing''.
7.1.2, Paragraph 1, Page 175
In the last line, ``explicity'' should be ``explicitly''.
7.1.7, Paragraph 2, Page 179
In the last line, ``for'' should be ``of''.
7.1.8, Paragraph 3, Page 181
``return'' should be ``returns''. (Also annex C.)
7.2.1.1, Paragraph 2, Page 183
In line 4, ``name of the source file, and the source line
number'' should be ``name of the source file, the source
line number, and the name of the enclosing function''.
5 SC22/WG14 N799
7.3.1.3, Page 186
The isblank function was not approved by the committee and
should not have appeared in the draft.
7.4, Paragraph 3, Page 190
Starting at the end of the first line, ``character
constants'' should be ``constants''.
7.4.5, Paragraph 1, Page 199
The reference to footnote 151 should be to 149 instead.
7.5, Paragraph 3, Page 202
The reference to footnote 153 should be moved to the end of
the sentence.
7.5.1, Paragraph 2, Page 203
In the very last line, there should be a reference to
strfxtime as well as strftime.
7.7.8.3, Paragraph 3, Page 236
In the last line, ``too large'' should be ``too large or too
small''.
7.11, Paragraph 3, Page 266
The portion of the paragraph between the two lists should
read:
which expand to constant expressions with distinct
values that have type compatible with the second
argument to, and the return value from, the signal
function, and whose values compare unequal to the
address of any declarable function; and the
following, which expand to positive integer
constant expressions with type int and distinct
values that are the signal numbers...
7.13.6.1, Paragraph 3, Page 288
In the list item beginning ``An optional hh...'', the words
for hhn have been omitted.
7.13.6.1, Paragraph 14, Page 293
The header should read "Environmental limits".
SC22/WG14 N799 6
7.13.6.2, Paragraph 11, Pages 297-298
In the descriptions of the s, [, and c format specifiers,
there should not be a paragraph break before the paragraph
beginning ``If an l qualifier is present...''.
7.14.5, Footnote 227, Page 336
The last line of the footnote is missing. It should read:
(char *)p < (char *)base + nmemb * size
7.16.1, Paragraph 1, Page 357
In the first line, ``four types and several functions''
should be ``several types and functions''.
7.16.2.3, Paragraphs 5-6, Page 360
The last line of paragraph 5 and all of paragraph 6 should
be deleted.
7.16.2.6, Paragraph 3, Page 363
At the end of the block of // comments, there should be one
more:
// if the offset cannot be determined.
7.16.3.6, Paragraph 6, Page369
``%P'' should be ``%p'' and "am" and "pm" should not be in
program font.
7.18.2.1.1, Paragraph 2, Page 373
``Th'' should be ``The''.
7.18.2.1.3, Page 373
The iswblank function was not approved by the committee and
should not have appeared in the draft.
7.18.2.2, Paragraph 1, Page 376
The reference to subclause 4.5.2.1 should be to 7.18.2.1.
7.19.2.1, Paragraph 2, Page 381
The last sentence is duplicated.
7.19.2.1, Paragraph 2, Page 382
In the list item beginning ``An optional hh...'', the words
7 SC22/WG14 N799
for hhn have been omitted.
7.19.2.1, Paragraph 14, Page 388
The header should read "Environmental limits".
7.19.2.1, Paragraph 16, Page 388
This should be a normal Forward References section -- it
should not have a paragraph number and the header should be
in bold font.
7.19.2.2, Paragraph 11, Pages 391
In the second line of the description of the [ format
specifier, ``f'' should be ``If''.
7.19.2.2, Paragraph 11, Pages 391-392
In the descriptions of the s, [, and c format specifiers,
there should not be a paragraph break before the paragraph
beginning ``If an l qualifier is present...''.
7.19.2.2, Examples, Page 393
There should not be numbered paragraphs in the examples.
7.19.2.2, Paragraph 22, Page 394
This should be a normal Forward References section -- it
should not have a paragraph number and the header should be
in bold font.
7.19.7.3.1, Paragraph 4, Page 426
This should be a normal Forward References section -- it
should not have a paragraph number and the header should be
in bold font.
7.19.7.3.3, Paragraph 3, Page 426
``a value between'' should be ``or a value between''.
Annexes
The annexes and the index are all formatted wider than the
main text.
Annex A, Page 434
The hyphens in the standards' designations should be dashes.
SC22/WG14 N799 8
F.9.3.11, Paragraph 1, Page 501
In the second bullet item, there should be a space between )
and ``returns''.
G.5, Paragraph 5, Page 514
The reference to subclause 7.9.2 should be to 7.8.2.
Index, Pages 559-570
The index, which was produced manually, is both incomplete
and inaccurate. I have since reviewed and corrected it and
used that information to continue the process of adding
index macros to the text so as to generate the index
automatically as part of the formatting process. I have
also added the automatic index generation to the formatting
process and have produced an enhanced and corrected index to
CD1 (N800) which can be used to aid in the review process.
Note that there is still a lot of work to be done on the
index; I would appreciate any suggestions for additional
entries, additional cross references, missing references, or
excessive references.
3. Suggested Editorial Changes
General
All hyphenated terms should be examined to determine where
the hyphenation is appropriate and where it isn't. All
italicized terms should also be examined.
General
References to other standards should not include specific
versions except in the References and Bibliography.
5.1.1.2, Paragraph 6, Page 9
Since we now allow concatenation of character and wide
string literals, this paragraph should be rewritten to
simply:
Adjacent string literal tokens are concatenated.
5.2.1 Paragraph 4, Page 16
Universal character names should have their own subclause
(like trigraphs do).
I also suggest changing the description to:
9 SC22/WG14 N799
The universal character name \Unnnnnnnn designates
the character whose character short identifier (as
specified by ISO/IEC 10646-1) is nnnnnnnn.
Similarly, the universal character name \unnnn
designates the character whose character short
identifier is 0000nnnn.
5.2.4.2.2, Paragraph 9, Page 28
A better wording is:
The values given in the following list shall be
replaced by implementation-defined expressions
with [positive?] values that are less than or
equal to those shown:
6.1.2.5, Footnote 29, Page 40
I suggest rewording the first two sentences to:
An implementation may define new keywords that
provide alternative ways to designate a basic (or
any other) type; this does not violate the
requirement that all basic types be different.
6.1.3.1, Paragraph 1, Page 47
The definition of hexadecimal digit really belongs in
6.1.3.2 (Integer constants) since there is text there
explaining it. It would perhaps be best to switch these two
sections.
6.1.3.4, Paragraph 5, Page 50
The lists of types for constants would be much easier to
read as a table.
6.5.2.2, Paragraph 5, Page 108
It would be better to say:
The type is incomplete until after the } that
terminates the list.
since that's what we say for structure and union specifiers
(cf., 6.5.2.1, Paragraph 6, Page 104).
Clause 7
Many of the subclauses should be rearranged to put them into
alphabetical order.
SC22/WG14 N799 10
7.4.5, Paragraph 1, Page 199
Since footnote 149 (which is what this is supposed to refer
to) is so far away, it should be replicated here or this
subclause should be moved to immediately after 7.4.2.
7.7, various
A number of subclauses in this section write out equations
using words such as ``x raised to the power y''. I suggest
using equations in all cases.
7.7.6.5, Paragraphs 2-3, Page 230
This subclause uses ``base-ten'', other subclauses use
``base-2''; we should be consistent. I suggest using
numbers everywhere.
7.13.3, Paragraph 7, Page 279
Since this paragraph is talking about the standard streams,
it might be better to move it to subclause 7.13.2 (Streams).
7.16.2.4, Paragraph 2, Page 361
At the end of the line, ``takes into account of the
additional members'' should be ``takes into account the
values of the additional members''.
7.18.2.1, Paragraph 2, Page 372
In the second line, it would be better to not mention the
exact number of functions (it's easy to overlook if the list
ever changes). Similarly for 7.18.2.2.1 paragraph 3 (page
376) and 7.18.2.2.2 paragraph 3 (page 377).
H.2.4, Paragraph 1, Page 525
The ugly arrows should be replaced by real arrows.
K.2, Page 537, Bullet 3
Similarly, converting between a pointer to an object or
incomplete type and a pointer to a function causes undefined
behavior. Subclause 6.2 is also relevant.
K.2, Page 537, Bullet 12
It should be clarified that this only applies to relational
comparisons, not equality comparisons.
K.2, Page 538, Bullet 14
I think what this is supposed to say is ``An attempt is made
11 SC22/WG14 N799
to access an object through both a restrict-qualified
pointer and another pointer not based on it.''
4. Suggested Possibly-substantive Changes
3.18, Paragraph 3, Page 6
An implementation need not successfully translate a given
program if it exceeds a translation limit.
6.1.3.1, Paragraph 1, Page 47
In the first two productions for hexadecimal floating
constant, the binary exponent part should be optional
(parallel to decimal floating constant).
5. Open Issues
Clause 4, Paragraph 2, Page 7
Should <stdbool.h> be added to the list of required headers
for freestanding implementations?
6.1, Paragraph 3, Page 31
Are all the italicized terms really appropriate?
6.1.3.1, Paragraph 1, Page 47
The 0x and 0X prefixes are used in multiple places, it might
simplify the grammar to factor them out into their own
nonterminal.
Clause 7
There are no synopses for the float and long double versions
of the math routines and there are a number of synopses that
basically duplicate or refer to other synopses. We should
consider allowing multiple synopses for a family of
functions with a single description like the Unix man pages
have traditionally done.
7.7.11.2, Paragraph 2, Page 242
It is not clear what the last line (``a call to the nan
function is unspecified'') is supposed to mean.
7.11.2.1, Paragraph 3, Page 268
It is not clear when the raise function is permitted to
fail; is it only for an invalid signal number or are there
other conditions?
SC22/WG14 N799 12
7.13.5.2, Paragraph 4, Page 283
It is not clear what happens if stream is a null pointer and
a write error occurs on one of the streams being flushed.
7.13.6.2, Paragraph 11, Page 298
In the description of the [ conversion specifier, it is not
clear whether the scanset is composed of single byte
characters or multibyte characters.
7.14.3.4, Paragraph 3, Page 334
The comparison described in the last sentence results in
undefined behavior if the object has moved.
7.16.1, Paragraph 4, Page 358
It is not always clear what happens if a member is outside
its normal range when calling functions in the subclause.
7.18.2.1, Pages 372-377
Many of these functions provide very little guidance as to
their intended semantics other than the similarity between
their names and the names of the ordinary character
functions. It seems like we should say a bit more than we
currently do.
Annex F
There are no entries for ilogb, scalbln, llrint, llround, or
nextafterx. We should say something about them, just so it
doesn't look like an oversight.
K.2, Page 535, Bullet 4
The first character of an identifier can't be a digit, the
syntax doesn't allow it.
K.2, Page 540, Bullet 10
This isn't undefined behavior. I think the situation that
this is supposed to be describing is that when a macro
expansion ends with a macro name which is ``painted blue'',
and that macro is a function-like macro, and the first token
of the remaining source-file tokens is a (, it was not clear
whether that macro was to be replaced or not and thus it was
undefined behavior to depend on one or the other.
Rereading the subclause on rescanning again, it now looks to
me like it is clearly specified that the macro is not
replaced. Does anyone disagree?
13 SC22/WG14 N799
-- Larry Jones