JTC1/SC22/WG14
N834
DOCUMENT WG14 N834
J11/98-033
This document contains the US Public comments on CD1 recieved
from NCITS. No changes have been made to comment numbers or
text.
-------------------------------------------------------------------------------
Comment # Submitter Receipt Date
Comment #1 David R. Tribble January 21, 1998
If the Technical Committee action is to accept in whole or in part a
proposal contained in the comment, the changes should be sent to the
Coordinator of Standards Processing together with any TC comments
supporting the change. If the TC action is to reject in whole or in part =
proposals contained in the comment, the response should provide the
rationale for the rejection.
The comment should be discussed at the next TC meeting, and if not
definitively responded to at once, an interim acknowledgment should be
sent along with an estimated date of action.
The final response to the commenter must include the provision that the
commentor has twenty working days from the postmark of the technical
committees response to indicate, in a written statement, acceptance or
rejection of the TC response.
PUBLIC REVIEW COMMENT #1
Date: Wed, 21 Jan 1998 11:09:40 -0600
To: ddonovan@itic.nw.dc.us
From: David R Tribble <david.tribble@central.beasys.com>
Subject: Comments on ISO/IEC 9899 (C9X) draft
Public Comment Number(s) PC-____ to PC-____
ISO/IEC CD 9899 (SC22N2620) Public Comment
Date: 1998-01-21
Author: David R. Tribble
Author Affiliation: Self
Postal Address: 6004 Cave River Dr.
Plano, TX 75093-6951
USA
E-mail Address: dtribble@technologist.com
david.tribble@central.beasys.com
dtribble@flash.net
Telephone Number: +1 972 738 6125, 16:00-00:00 UTC
+1 972 964 1729, 01:00-05:00 UTC
Fax Number: +1 972 738 6111
Number of individual comments: 2
------------------------------------------------------------------------
Comment 1.
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.
------------------------------------------------------------------------
Comment 2.
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 REVIEW COMMENT #2
Date: Thu, 05 Feb 1998 20:31:32 -0600
To: ddonovan@itic.nw.dc.us
From: David R Tribble <david.tribble@central.beasys.com>
Subject: Comments on ISO/IEC CD 9899 (C9X)
Public Comment Number(s) PC-____ to PC-____
ISO/IEC CD 9899 (SC22N2620) Public Comment
Date: 1998-02-05
Author: David R. Tribble
Author Affiliation: Self
Postal Address: 6004 Cave River Dr.
Plano, TX 75093-6951
USA
E-mail Address: dtribble@technologist.com
david.tribble@central.beasys.com
dtribble@flash.net
Telephone Number: +1 972 738 6125, 16:00-00:00 UTC
+1 972 964 1729, 01:00-05:00 UTC
Fax Number: +1 972 738 6111
Number of individual comments: 1
------------------------------------------------------------------------
Comment 1.
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 REVIEW COMMENT #3
Date: Mon, 09 Feb 1998 12:22:57 -0600
To: ddonovan@itic.nw.dc.us
From: David R Tribble <david.tribble@central.beasys.com>
Subject: Comments on ISO/IEC CD 9899 (C9X)
Public Comment Number(s) PC-____ to PC-____
ISO/IEC CD 9899 (SC22N2620) Public Comment
Date: 1998-02-09
Author: David R. Tribble
Author Affiliation: Self
Postal Address: 6004 Cave River Dr.
Plano, TX 75093-6951
USA
E-mail Address: dtribble@technologist.com
david.tribble@central.beasys.com
dtribble@flash.net
Telephone Number: +1 972 738 6125, 16:00-00:00 UTC
+1 972 964 1729, 01:00-05:00 UTC
Fax Number: +1 972 738 6111
Number of individual comments: 1
------------------------------------------------------------------------
Comment 1.
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 REVIEW COMMENT #4
Date: Tue, 10 Feb 1998 21:00:46 -0600
To: ddonovan@itic.nw.dc.us
From: David R Tribble <david.tribble@central.beasys.com>
Subject: Comments on ISO/IEC CD 9899 (C9X)
Public Comment Number(s) PC-____ to PC-____
ISO/IEC CD 9899 (SC22N2620) Public Comment
Date: 1998-02-10
Author: David R. Tribble
Author Affiliation: Self
Postal Address: 6004 Cave River Dr.
Plano, TX 75093-6951
USA
E-mail Address: dtribble@technologist.com
david.tribble@central.beasys.com
dtribble@flash.net
Telephone Number: +1 972 738 6125, 16:00-00:00 UTC
+1 972 964 1729, 01:00-05:00 UTC
Fax Number: +1 972 738 6111
Number of individual comments: 1
------------------------------------------------------------------------
Comment 1.
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 =3D NULL; // Should be 0
char ch =3D 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 REVIEW COMMENT #5
Date: Fri, 13 Feb 1998 12:56:52 -0600
To: ddonovan@itic.nw.dc.us
From: David R Tribble <david.tribble@central.beasys.com>
Subject: Comments on ISO/IEC CD 9899 (C9X)
Public Comment Number(s) PC-____ to PC-____
ISO/IEC CD 9899 (SC22N2620) Public Comment
Date: 1998-02-13
Author: David R. Tribble
Author Affiliation: Self
Postal Address: 6004 Cave River Dr.
Plano, TX 75093-6951
USA
E-mail Address: dtribble@technologist.com
david.tribble@central.beasys.com
dtribble@flash.net
Telephone Number: +1 972 738 6125, 16:00-00:00 UTC
+1 972 964 1729, 01:00-05:00 UTC
Fax Number: +1 972 738 6111
Number of individual comments: 1
------------------------------------------------------------------------
Comment 1.
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')=3D=3D0, while Microsoft Visual C defines
isprint('\t')!=3D0.) 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)!=3D0 and isprint(X)!=3D0, 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.)
PUBLIC REVIEW COMMENT #6
ISO/IEC CD 9899 (SC22N2620) Public Comment
Date: 1998-2-24
Author: Andrew Josey
Author Affiliation: The Open Group
Postal Address:
The Open Group
Apex Plaza, Forbury Road
Reading
RG1 1AX
United Kingdom
E-mail Address: <ajosey@rdg.opengroup.org>
Telephone Number: +44 118 950 8311
Fax Number: +44 118 950 0110
Number of individual comments: 1
Comment 1.
Category: Feature that should be included
Committee Draft subsection: 7.16.3.6
Title: Century handling in strftime()
Detailed description:
(century handling in strftime)
There is no century handling within strftime(). With the new century
at hand this needs addressing . ISO C should include the %C
conversion specification which has been in the X/Open Portability
Guide since XPG4 (1992).
After %c insert a new line
%C is replaced by the century number (the year divided by 100 and
truncated to an integer) as a decimal number [00-99]
PUBLIC REVIEW COMMENT #7
ISO/IEC CD 9899 (SC22N2620) Public Comment
Date: 1998-03-03
Author: Steve Summit
Author Affiliation: individual
Postal Address: 5812 15th Ave. NE
Seattle, WA 98105 USA
E-mail Address: scs@eskimo.com
Telephone Number: +1 206 522 7534
Fax Number: n/a
Number of individual comments: 97
-----------------------------------------------------------------
[begin boilerplate]
Before I dive in with my comments, I have several apologies and
disclaimers. I'm sorry that these comments are coming in at the
last minute, and that there are so many of them. Most of them,
at least, are editorial; I haven't made too many normative
suggestions. My main goal is to help keep the revised document
up to the high standards (for succinctness and accuracy) of its
predecessor.
I do not require feedback on any of these suggestions. I fully
understand (without rancor) that many of them will not be used;
the committee member(s) reviewing them need not feel guilty about
abandoning them, and need not apologize to me for doing so.
Where I have categorized a comment as "Request for information/
clarification", it is invariably a rhetorical question suggesting
that the Draft's wording may need to be clarified; I am not
requesting a personal response.
I apologize, too, for the naivete which I'm sure some of these
comments will display. I haven't kept up with the committee's
work as much as I'd like, and some of the issues which I've
expressed confusion about may well be straightforward. (On the
other hand, I'm not completely uninformed about C, as I have been
programming in it for about 20 years, maintaining the Usenet FAQ
list on it for the past 10, and teaching it for the past 5.)
Where I offer suggested new wording, I use two notations to
suggest alternatives: words in square brackets [] are optional,
and words between braces, separated by slashes
(e.g. {this/that/the other}) are alternatives to be chosen among.
I have scribbled more comments on my printout of the draft than
I have had time to present here before the deadline. If any
committee member is interested in, and somehow has time for,
polishing the wording of the document, I would be happy to pass
on more comments in the same vein (restricting them, of course,
to editorial changes, non-normative contribution, and requests
for clarification).
[end boilerplate]
I have divided my comments into three separate submissions.
This one covers sections (clauses) 1 through 6. The second one
covers section 7 and a few of the annexes, and the third one
contains editorial comments and suggestions of a somewhat more
nit-picky nature.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 1.
Category: Request for information/clarification
Committee Draft subsection: Introduction
Title: "recommended practice" part of Standard?
Detailed description:
Are the "Recommended practice" subsections part of the Standard?
By analogy with examples and footnotes, I suspect that they're
not.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 2.
Category: Inconsistency
Committee Draft subsection: 1 / 5.2.4.1
Title: size/complexity constraints?
Detailed description:
Section 1 para. 2 bullet 5 says that the size and complexity are
not constrained, but the translation limits in section 5.2.4.1
seem to provide exactly such constraints.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 3.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 3
Title: typo #1
Detailed description:
I think the word "by" is missing in front of the word "being".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 4.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 3.2
Title: "actual parameter" oxymoron
Detailed description:
I would *not* say that (actual) arguments are ever known as
"actual parameter"; the word "parameter" strongly suggests
"formal parameter". Moreover, the pair of words "actual
parameter" appears nowhere outside of section 3.2. Please omit.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 5.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 3.16
Title: "formal argument" oxymoron
Detailed description:
Similarly, "formal argument" strikes me as poor usage, and
appears nowhere outside of section 3.16. Please omit.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 6.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 3.18
Title: undefined behavior and diagnostics
Detailed description:
The wording at the end of para. 1 could be read o suggest that
termination upon undefined behavior *does* require a diagnostic.
I suggest changing the last "(with the issuance of a diagnostic
message)" to "(with or without the issuance of a diagnostic
message)".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 7.
Category: Request for information/clarification
Committee Draft subsection: 5.1.1.1
Title: "linked" undefined
Detailed description:
The term "linked" appears in the last line of para. 1 and in
several other places, with fairly significant implication, and
although you and I know what it means, it is nowhere defined.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 8.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 5.1.1.2
Title: misplaced constraint on universal-character-name
Detailed description:
The second sentence of para. 2 seems as if it belongs in section
5.2.1 para. 5. (I'm not sure I agree with the constraint, but I
don't understand universal character names well enough to
comment.) At any rate, the "Forward references" for 5.1.1.2
should probably include 5.2.1.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 9.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 5.1.2.2.1
Title: argc/argv modifiability, part 1
Detailed description:
I'd suggest removing the words "parameters argc and argv and the";
these parameters are obviously modifiable, as all parameters are.
(See also Comment 10.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 10.
Category: Request for information/clarification
Committee Draft subsection: 5.1.2.2.1
Title: argc/argv modifiability, part 2
Detailed description:
Is the array of pointers to char pointed to by argv modifiable?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 11.
Category: Normative change to existing feature retaining the original =
intent
Committee Draft subsection: 5.1.2.2.3
Title: exit / return from main equivalence
Detailed description:
I suggest moving the text of footnote 10 into the Standard.
This is a frequently debated issue, and I'm not aware that
footnote 10's statement is implied anywhere else in the Standard.
(Indeed, section 5.1.2.2.3 para. 1 seems to suggest otherwise.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 12.
Category: Request for information/clarification
Committee Draft subsection: 5.2.1
Title: other characters in comments, etc.
Detailed description:
What is the behavior when "any other characters" are encountered
*in* "a character constant, a string literal, a header name, a
comment, or a preprocessing token that is never converted to a
token"? Must they be allowed? I'd say it's implementation
defined, but I think the Standard should say so.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 13.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 5.2.1.1
Title: trigraph definition
Detailed description:
I'm not sure that word "corresponding" is obvious enough; I
might be more explicit and say "each of the three-character
sequences in the first column below is replaced with the
corresponding single character from the second column."
Also, this section may rate a forward reference to section 6.1.5;
when at first I didn't find the digraphs here, I thought they'd
been removed.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 14.
Category: Request for information/clarification
Committee Draft subsection: 5.2.1.2
Title: multibyte sequences/strings
Detailed description:
Although the term "multibyte character" is nicely defined,
the terms "multibyte sequence" and "multibyte string" are
introduced along the way (i.e. in later sections) as if we
already know what they are, and their precise definitions are
very hard to ferret out. It would be nice to collect them
here (or perhaps in section 3.14).
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 15.
Category: Request for information/clarification
Committee Draft subsection: 5.2.1.2
Title: source multibyte characters
Detailed description:
Paragraph 2 seems to be constraining source files, not the source
character set. (I'm not sure how to clarify this.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 16.
Category: Normative change to intent of existing feature
Committee Draft subsection: 5.2.4.1
Title: object limit of 32767 should be retained
Detailed description:
In the previous revision of this Standard, the limit on the size
of an object was 32767. This allowed a 16-bit implementation to
use a 16-bit signed type for ptrdiff_t. If an implementation
must be able to handle at least one object of size 65536, and if
this object is an array of char, ptrdiff_t must be (at least) a
17-bit type, meaning a 32-bit type in practice, leading to an
unacceptable overhead on all *other* pointer differences. I feel
that the translation limit of 32767 bytes on the size of one
object should be retained.
(I comment separately on section 7.4.5, with respect to the same
issue.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 17.
Category: Other: comment
Committee Draft subsection: 5.2.4
Title: environmental limits scattered
Detailed description:
Several environmental limits appear elsewhere (specifically:
in sections 7.13.2 para. 7, 7.13.3 para. 14, 7.13.4.4 para. 6,
7.13.6.1 para. 14, 7.14.2.1 para. 5, 7.14.4.2 para. 3,
7.19.2.1 para. 14), and this fact may be worth noting somewhere
in section 5.2.4.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 18.
Category: Other: comment
Committee Draft subsection: 5.2.4.1
Title: some translation limits repeated
Detailed description:
A few of the translation limits in section 5.2.4.1 are repeated
elsewhere (specifically: in sections 6.5.5 para. 7, 6.1.2 para. 6,
6.6.4.2 para. 4), redundantly.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 19.
Category: Other: comment
Committee Draft subsection: 5.2.4.2
Title: numerical limits scattered
Detailed description:
Several numerical limits appear elsewhere (specifically: in
sections 7.4.2 and 7.4.5), and this fact may be worth noting in
section 5.2.4.2.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 20.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 5.2.4
Title: environmental limits scattered; some repeated
Detailed description:
In light of comments 17 to 19, para. 1 should probably
say "...summarizes most of the environmental limits...".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 21.
Category: Request for information/clarification
Committee Draft subsection: 6.1.2.2
Title: multiply-defined symbols
Detailed description:
Should paragraph 7 say "within a translation unit and a scope"?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 22.
Category: Request for information/clarification
Committee Draft subsection: 6.1.2.4
Title: jumps into blocks containing "variably modified" objects
Detailed description:
In para. 3, in the sentence beginning "If the object is variably
modified", it is not clear to me what "variably modified" means
(or at least, it wasn't on first reading). Does this sentence
describe the antithesis of the previous sentence, namely for
objects that *do* have a variable length array type? If so,
please use identical terminology.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 23.
Category: Request for information/clarification
Committee Draft subsection: 6.1.2.5
Title: better description of "rank", part 1
Detailed description:
The word "rank" appears out of a clear sky in para. 7. It might
be nice to introduce or motivate this term with a sentence like
"For the purposes of describing the default conversions, each
{arithmetic/integer} type is assigned a rank." It might also be
nice, perhaps in a footnote, to provide a few words or an
example connecting this new concept of rank back to the more
familiar wording used in K&R or the previous Standard. (I see
that sec. 6.1.2.5 forward references sec. 6.2.1.1; perhaps that
suffices.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 24.
Category: Normative change to existing feature retaining the original =
intent
Committee Draft subsection: 6.1.2.5
Title: type and representation of `complex'
Detailed description:
With respect to para. 12, a complex type presumably also has the
same representation and alignment restrictions as the obvious
two-member struct, and this fact is probably worth explicitly
noting (i.e. specifying/requiring). (I'm not sure if homogeneous
structs are otherwise guaranteed to be equivalent to arrays, and
the reader may not be, either. But presumably if this guarantee
of equivalence to an array is considered useful, the analogous
guarantee for structs would be, too.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 25.
Category: Request for information/clarification
Committee Draft subsection: 6.1.2.5
Title: optionally named members?
Detailed description:
Does the word "optionally" in the second and third bullets of
para. 17 refer to unnamed bit-field members, or to something else?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 26.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.2.6
Title: multiply defined symbols
Detailed description:
Presumably, incompatible declarations of the same object or
function are undefined only if in different translation units.
Otherwise, they require a diagnostic. (If the wording here is
changed, change Annex K sec. K.2, also.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 27.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.2.8.1
Title: vague pronoun reference #1
Detailed description:
The word "that" in the first sentence of para. 2 has a vague
antecedent. I suggest replacing it with "a particular".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 28.
Category: Request for information/clarification
Committee Draft subsection: 6.1.3.1
Title: floating-point constant overflow
Detailed description:
Perhaps I'm missing something, but it doesn't look as if para. 3
explains what happens if the the scaled value is *not* in the
range of representable values for its type. (The question is
particularly interesting since sec. 7.7 para. 4 makes explicit
reference to compile-time overflow of a floating-point constant.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 29.
Category: Feature (specification) that should be included
Committee Draft subsection: 6.1.3.4
Title: character constant limit
Detailed description:
I'm surprised there's no limit on the length of a character
constant, as there is for a string literal (see sec. 5.2.4.1
bullet 16, of course). I believe a reasonable limit on the
length of a character constant would be 4.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 30.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.5
Title: operator pairing wrt translation phase
Detailed description:
The first sentence of para. 2 should include the words "after
translation phase 4", as sec. 6.1.6 does.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 31.
Category: Request for information/clarification
Committee Draft subsection: 6.1.5
Title: "designator"
Detailed description:
The word "designator" appears out of a clear sky in para. 3.
Grepping the rest of the document for this term reveals that
"function designator" is probably meant.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 32.
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.1.7
Title: undefined characters in header names
Detailed description:
I believe that the behavior if unusual characters appear in
h-char-sequences and q-char-sequences should be
implementation-defined, not undefined.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 33.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.9
Title: continued // comments
Detailed description:
The fact that \ continues // comments is arguably wrong, and the
fact that the preexisting translation phases forced this
interpretation was (to my mind) the strongest arguments against
adopting them. Given the surprisingness of this result, I'd say
it rates a footnote ("Since backslash continuation occurs in
translation phase 2, and comments are parsed in translation phase
3, a \ effectively continues a // comment; that is, the \\ does
not "protect" the \ from interpretation") as well as appearing in
the examples.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 34.
Category: Request for information/clarification
Committee Draft subsection: 6.2.1.1
Title: better description of "rank", part 2
Detailed description:
As mentioned in comment 23, it might be nice to have a footnote
connecting this new concept of rank back to the more familiar
wording used in K&R or the previous Standard.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 35.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.2.2.3
Title: compatibility of converted function pointer types
Detailed description:
I believe that para. 8 should end with "...not compatible with
the type of the converted pointer, the behavior is undefined."
The function being called is always compatible with the called
function!
I think it would also be possible (and perhaps beneficial) to
delete the last sentence entirely; I believe that sec. 6.3.2.2
para. 8 says the same thing.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 36.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.2.2.3
Title: misc. wording #1
Detailed description:
In footnote 55, the word "yields" could be replaced (for more
clarity, I think) with "would yield".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 37.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.2.2.3
Title: misc. wording #2
Detailed description:
In footnote 56, the words "correctly aligned" either need to be
in italics, or in quotes, or replaced with the words "of correct
alignment".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 38.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3
Title: undefined expression wording
Detailed description:
Although I understand it perfectly well now, for the longest
time the classic second sentence of para. 2 was almost
completely opaque to me. I might offer this replacement:
Furthermore, an object may not be accessed and modified
unless the access is { to determine / part of the
calculation of } the value to be stored.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 39.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3
Title: evaluation order and syntax
Detailed description:
The words "Except as indicated by the syntax" can be very
misleading. Many people believe that explicit parentheses,
or "operator precedence", *do* define aspects of evaluation
order which we know to be undefined. Changing the word
"subexpressions" later in the paragraph to "operands" might help.
(Unfortunately I can't immediately think of a more substantial
clear rewrite.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 40.
Category: Request for information/clarification
Committee Draft subsection: 6.3
Title: "object having no declared type"
Detailed description:
Is an "object having no declared type" one derived from malloc()?
(This paragraph is fascinating, by the way.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 41.
Category: 6.3.1.1
Committee Draft subsection:
Title: "unadorned" name?
Detailed description:
The word "unadorned" appears almost nowhere else in this document.
Is its meaning sufficiently clear? (Just now, I'm not even sure
I understand its intent.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 42.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.2.2
Title: semantics of function call semantics
Detailed description:
I commend the rewording over the 1989/1990 version, which was
nearly impossible to read. However, the breaking up into
paragraphs (which is otherwise a good idea), combined with the
paragraph numbers, leads to a new parsing challenge. Paragraph 6
is continuing the case that began in para. 5, but this may not
be obvious upon first reading. (When I first read para. 6 in
isolation, I could not understand it *at* *all*.) If at all
possible, I would remove the explicit paragraph number from
what is now para. 6.
Having learned that paragraphs 5 and 6 go together, we might then
assume that paragraphs 7 and 8 go together, but we'd be stymied
again! Paragraph 8 applies to both cases (the non-prototype case
of paras. 5/6 and the prototyped case of para. 7). It would be
nice to make this connection more clear as well.
Also, the clause "or if the prototype ends with an ellipsis" in
para. 6 seems redundant; it seems that para. 8 should cover (or
be made to cover) this case, as well, i.e. by the definition of
compatible type for function pointers (sections 6.1.2.6 and
6.5.5.3).
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 43.
Category: Other (comment)
Committee Draft subsection: 6.3.2.3
Title: -> definition
Detailed description:
Is there any reason not to define p->m as (*p).m? That seems
tidiest.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 44.
Category: Request for information/clarification
Committee Draft subsection: 6.3.2.5
Title: confused about example 8
Detailed description:
I'm missing the point of example 8. The only difference I can
see between the two loops concerns the explicit braces, which I
guess is the point, but I'm still not seeing the point, or what
would be the same or different. The introductory paragraph
talks not about blocks but only about within/without a function
body, and the words "same sequence of values for the objects
associated with their respective compound literals" are just
meaningless.
Shouldn't the example be contrived to show some *difference*
between the two loops, i.e by having function f() inspect them
very carefully, or try to modify them?
Also, to avoid more confusion, the function in the following
example 9 should probably have a different name.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 45.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.3.3
Title: mildly confusing sequencing of - and ~
Detailed description:
The wording of paras. 3 and 4 is mildly awkward -- it sounds a
bit as if the operation is performed, then the integer promotion
is performed, then the result is obtained. (Inserting "first"
before "performed" in both places would help.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 46.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.3.4
Title: misc. wording #3
Detailed description:
In para. 4, the word "as" or a comma should be inserted between
"size_t" and "defined".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 47.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.6
Title: wording in example
Detailed description:
"know" should be "known". Also, it might read better in the
subjunctive: "If array... were declared..., and pointer... were
declared..., the results would be the same."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 48.
Category:
Committee Draft subsection:
Title: Normative change to intent of existing feature
Detailed description:
Is it really the intent that bits not quietly fall off the left
edge when shifting signed values to the left, but rather that
the behavior be undefined? This seems a major change with
respect to the 1989/1990 version, although reviewing it, I see
that it didn't mention the signed case explicitly at all.
Unless there are viable architectures which are known to have
problems with this case, I'd very much like to see the signed
case well-defined as well. (Is the problem those pesky padding
bits?)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 49.
Category: Other (comment)
Committee Draft subsection: 6.3.8
Title: comparison of incomplete pointers
Detailed description:
Paragraph 2 bullet 3, para. 5 2nd sentence, and para. 5 last
sentence combine to say that if p and q have type void *, the
expression p >=3D q yields 1 if p =3D=3D q and is undefined if p !=3D q.
(I presume this is the intent.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 50.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.9
Title: pointer equality testing
Detailed description:
The wording in para. 4 seems cumbersome. Why not at least
shorten the third and fourth sentences to "Two pointers to
function types compare equal if and only if: they are both null
pointers or both point to the same function."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 51.
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.3.9
Title: floating point equality
Detailed description:
Does there need to be an explicit caveat about the limitations of
testing for floating point equality? For example, I've heard it
alleged that the fragment
double a =3D b + c;
if(a !=3D b + c) printf("impossible!")
might in fact print "impossible", if the register used to hold
the intermediate result of the second addition has more precision
than the object used to store c.
(Perhaps I'm wrong, or perhaps this issue is covered elsewhere.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 52.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.13, 6.3.14
Title: misleading wording concerning short-circuiting
Detailed description:
Since most operators do not guarantee left-to-right evaluation,
the words "Unlike the bitwise binary & operator" in sec. 6.3.13
para. 4 are potentially misleading. (By singling out & for this
comparison, the reader might assume that it's unique in this
regard.) No harm is done by removing the clause, and the
analogous one in sec. 6.3.14 para. 4.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 53.
Category: Request for information/clarification
Committee Draft subsection: 6.3.15
Title: conditional operator cases: exhaustive?
Detailed description:
Perhaps I'm nitpicking, but though I used to think that the cases
describing the second and third operands were nicely complete,
now I'm wondering if they cover the (admittedly degenerate) forms
e?NULL:NULL and e?(void *)0:0 .
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 54.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.16.1
Title: char/int truncation
Detailed description:
The word "may" in example 1 is potentially misleading. I
suggest something like "the int value... will be truncated
(assuming sizeof(int) > sizeof(char))..."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 55.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.16.2
Title: semantics of compound assignment semantics
Detailed description:
The semantics description is one notch too terse. I'd expand it to
A compound assignment of the form E1 op=3D E2 is equivalent
to the simple assignment expression E1 =3D E1 op (E2), except
that the lvalue E1 is evaluated only once.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 56.
Category: Request for information/clarification
Committee Draft subsection: 6.4
Title: diagnostics on compile-time overflow
Detailed description:
The placement of para. 4 within the constraints section implies
that compile-time overflow is not undefined, but requires a
diagnostic. Is this in fact the case?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 57.
Category: Request for information/clarification
Committee Draft subsection: 6.5
Title: declaration constraints
Detailed description:
That word "excluding" in the parenthetical in para. 2 is a
stumper. What, exactly, does it mean? As worded, it seems like
it might be trying to say "above and beyond". It might be
clearer (if I even understand what it's trying to say) to reword
the parenthetical to "With the exception of function parameters
and members of structures or unions,", and place it at the front
of the sentence.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 58.
Category: Request for information/clarification
Committee Draft subsection: 6.5
Title: declaration constraints
Detailed description:
To the bullet list in para. 5, is there anything to be added
about tags? (See e.g. sec. 6.5.2.3 paras. 1, 5.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 59.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5
Title: declaration semantics
Detailed description:
I'd find para. 6 easier to read if "have" were changed to "specify".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 60.
Category: Normative change to existing feature retaining the original =
intent
Committee Draft subsection: 6.5.2
Title: complex declarations
Detailed description:
Shouldn't the keyword `complex' be able to appear alone,
defaulting to double complex? (Since keywords like `signed'
and `unsigned' can still appear alone, even though other
instances of default int are being weeded out, it seems harsh to
disallow plain complex.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 61.
Category: Normative change to existing feature retaining the original =
intent
Committee Draft subsection: 6.5.2.3
Title: tag type completion
Detailed description:
Presumably the type is *incomplete* (para. 3) until the closing
brace, and complete thereafter.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 62.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.3
Title: type qualifier examples
Detailed description:
Examples should not be in the running text of the Standard; the
sentence beginning "For example," in the middle of para. 7
should be moved or removed.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 63.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.3
Title: another qualified pointer example
Detailed description:
I propose adding a third example, concerning an obscure but not
uncommon situation:
The function call in the fragment
extern f(const char **q);
char *p;
f(&p);
violates a constraint (see section 6.3.16.1) and
requires a diagnostic. The call (or any assignment
of char ** to const char **) is unsafe, because if
function f were to perform the (valid) assignment
*q =3D &c;
where c was a const object, a later assignment by
the caller to *p (e.g. *p2 =3D 0) would in fact be
an attempted assignment to c.
This example is adapted from one in the book "C Programming
FAQs" which was supplied by Tanmoy Bhattacharya. The example
might go in section 6.3.16.1 instead, but it seems worth waiting
until qualified pointers have been fully introduced.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 64.
Category: Request for information/clarification
Committee Draft subsection: 6.5.3.1
Title: clarification of `restrict'
Detailed description:
My understanding of `restrict' is far from complete, so these
questions may be misguided. The last half of para. 4 did not
seem (to me) to rule out the second and third undefineds in
example 4.
In para. 5, I'm not sure what "attention" means, and I'm not
sure *where* the "visible identifiers" are visible.
Where is "the exception" mentioned in example 4 stated?
What is the antecedent of the pronoun "this" in "this permits"?
*If* I'm understanding this section at all, I'd insert
"(necessarily single)" before "array object" in para. 4, and
change "an object" to "a (possibly hypothetical) object" in para. 5.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 65.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.3.1
Title: `restrict' examples
Detailed description:
It might be worth noting that many examples of `restrict' can be
found in section 7, e.g. in the declarations of functions such
as sprintf, strcat, and memcpy.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 66.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.4
Title: `inline' examples and rationale
Detailed description:
The clause "by using, for example, an alternative to the usual
function call mechanism known as `inline substitution'" should be
moved into footnote 101 to keep examples out of the Standard.
(Also, the modifier "known as" is ambiguously placed; apparently
it is meant to attach to "an alternative" rather than "the usual
function call mechanism".)
It's too bad that this Standard will apparently not come with
a Rationale document, as this section could really use one.
What optimizations, really, are hinted/encouraged by `inline'?
(Apparently not inlining across translation units.) Which
optimizations must a compiler still perform entirely on its own,
without hints? (Probably inlining across translation units.)
If there are some compilers that will never perform inlining
and some that are able to do it even without hints, what sorts
of compilers are there in the middle, that will need the hints?
[That's not a leading question; I honestly don't know the
populations of any of the three categories.]
I think I finally figured out that the sentence beginning "An
inline definition does not provide..." in para. 6 is suggesting
that it's okay to place inline function definition *in header
files*, so that they will be available across translation units.
An example demonstrating this would probably be helpful.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 67.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.4
Title: naked subclause references
Detailed description:
I think the word "section" or "subclause" is missing before
"6.7" at the end of para. 8. (There are several examples of this
omission throughout the Draft; I'll point out a few others that
caught my eye. It's probably worth doing a global search for all
of them, if there's an easy way.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 68.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.5
Title: inconsistent metaname
Detailed description:
In paragraph 5, the two italicized words should presumably be the
same, both either "identifier" or "ident".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 69.
Category: Other (comment)
Committee Draft subsection: 6.5.5.2
Title: restriction on variable-length types
Detailed description:
The two sentences in para. 2 seem to say the same thing.
If they truly do, one can be removed; if there is some
slight difference, it should probably be emphasized.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 70.
Category: Request for information/clarification
Committee Draft subsection: 6.5.5.3
Title: identifier lists in function declarators
Detailed description:
Paragraph 3 is tricky. After reading it several times, I
finally realized that it is talking about identifier lists,
*not* parameter type lists. So it is saying (of course) that
these can only occur in function definitions, not external
declarations; the declaration
extern int f(a, b);
is meaningless. But isn't it the case that some of the
identifier lists in function definitions need to be empty as
well? Consider
int (*f(a, b))(c, d) { ... }
The identifier list "c, d" is just as meaningless, and should
probably be disallowed. (gcc correctly warns about these.)
If paragraph 3 needs fixing in this regard, paragraph 10 probably
does, too.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 71.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.7
Title: typedef examples
Detailed description:
In example 2, it should really say "pointed to by a value of type
tp1" and "pointed to by a value of type tp2". (Also, should the
last "and" be "or"?)
In example 3, the construction "function returning signed
int with one unnamed parameter with type pointer to function
returning signed int with one unnamed parameter with type signed
int" is impossible to parse. Changing the end of it to "and
{having/accepting} one unnamed parameter with type signed int"
would help.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 72.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.8
Title: the map is not the territory
Detailed description:
Paragraph 7 should end with "...the identifier shall name a
member of that type."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 73.
Category: Inconsistency
Committee Draft subsection: 6.5.2.1 / 6.5.8
Title: vacuous unions
Detailed description:
Section 6.5.8, para. 9 says that "A union object containing only
unnamed members has indeterminate value even after initialization",
but section 6.5.2.1 says that such a union is undefined.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 74.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.8
Title: default initialization order
Detailed description:
Paragraph 19 says "written in increasing subscript or member
order", to which I would add "except as modified by any explicit
designators."
Paragraph 22 says "largest indexed element with an explicit
initializer" which I would change to something like "element with
the largest (explicitly or implicitly) indexed explicit
initializer".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 75.
Category: Request for information/clarification
Committee Draft subsection: 6.5.8
Title: redundant initializers
Detailed description:
Is it forbidden to use designators to initialize multiple
elements of the same union? (For that matter, what happens
if a structure member or array element is multiply, explicitly
initialized?) Are the earlier initializers all "quietly
overridden" by the later, as in the discussion of example 11?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 76.
Category: Other (comment)
Committee Draft subsection:
Title: 6.6.4.2, 6.6.6.1
Detailed description:
Both sections prohibit jumping into blocks containing variably
modified types, and both sections use the word "shall" in a
constraint to do so. Therefore, a diagnostic is required.
Will the diagnostic be straightforward for the compiler to
generate?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 77.
Category: Request for information/clarification
Committee Draft subsection: 6.6.6.1
Title: jumping past variably-modified declarations
Detailed description:
The wording in example 2 about "jumping past" a variably-modified
declaration is just different enough from the Standard's wording
that I'm suspicious that it says the same thing.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 78.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.6.6.4
Title: valueless return statements
Detailed description:
I don't think (what's left of) paragraph 4 is even necessary any
more; now that valueless return statements in non-void functions
are disallowed (i.e. by para. 1), the remaining undefined
behavior is adequately covered by the requirements that the type
of a called function match its definition.
I was surprised, though, that the other sentence, from the
1989/1990 version, of what's now paragraph 4 was deleted.
("Reaching the } that terminates a function is equivalent to
executing a return statement without an expression." I guess that
statement couldn't remain, though, given the other changes.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 79.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.1
Title: typo #2
Detailed description:
In para. 5, I believe the word "case" is missing between "in
which" and "there shall not be an identifier".
Also, since this clause is utterly significant, I don't think it
should be a parenthetical.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 80.
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.7.1
Title: old-style parameters shouldn't have to be declared
Detailed description:
The new requirement is imposed that "every identifier in the
[old-style] identifier list shall be declared." This is a
useless halfway stance between continuing to allow old-style
definitions and banning them outright. Since old-style
definitions do, in the general case, tend to omit explicit
declarations for parameters of type int, many of them will need
rewriting, but if the maintainers of old code are to be forced
to revisit those old-style definitions, they will surely take
the opportunity to update them completely to prototype style.
I appreciate the fact that an attempt is being made to do away
with default int, but the default should remain here. There is
no point in forcing implementors to emit new diagnostics, and
maintainers to rewrite new definitions, unless it's to go all
the way and retire the old-style definitions. If they're to be
retained at all, they might as well be retained in peace.
(Although I suppose that those old-style definitions without
explicit return types will need some revision, anyway.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 81.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.1
Title: redundant constraints on function compatibility
Detailed description:
Paragraph 8 seems redundant; functions without ellipses simply
don't accept variable numbers of arguments, per language
elsewhere.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 82.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.1
Title: timing of conversions during function calls
Detailed description:
Paragraph 10 says that array and function arguments "are converted
to pointers before the call." This puts the horse behind the
cart; it should say "have already been converted to pointers (per
section 6.2.2.1)".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 83.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.1
Title: parameter scope
Detailed description:
I think that the text of footnote 120 should be in the body of
the Standard; I'm not aware of this specific point being made
(explicitly or even implicitly) elsewhere.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 84.
Category: Request for information/clarification
Committee Draft subsection: 6.7.2
Title: default size of 1 for incomplete arrays?
Detailed description:
The assertion in example 2 that the array acquires a size of 1
took me by surprise. Is this fact implied by the words "with an
initializer equal to 0" in para. 2, or what?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 85.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.1
Title: semantics of #include semantics
Detailed description:
Since preprocessing arithmetic is essentially interpreted,
without benefit of any declarations, I think that the first two
instances of the word "types" in para. 3 should be replaced by
"values".
Also, the word "subclause" is missing before "6.4", and the
antecedent of the pronoun "this" in "This includes
interpreting..." is vague.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 86.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.2
Title: h vs. q char sequences
Detailed description:
Where paragraph 3 describes the fallback search, I think it
should say
... reprocessed as if it read
# include <q-char-sequence> new-line
(especially since it is explicitly specified that contained >
characters are retained).
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 87.
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.8.3
Title: empty variable-length macro argument lists
Detailed description:
This has certainly been thought about by more minds than mine,
and there may well be issues I'm unaware of, but I'd say that the
variable-length part of a variable-length macro argument list
ought, just like those for functions, to be allowed to be empty.
Therefore, I would change "more" in para. 4 to "at least as many",
and I would add "(if any)" after "the trailing arguments" in
para. 12.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 88.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.3
Title: misc. wording suggestions re preprocessor macros
Detailed description:
The word "declared" in para. 6 seems wrong; macro parameters are
not formally declared. I'd just replace "uniquely declared"
with "unique".
It may be worth emphasizing (i.e. perhaps with a footnote) that
the rescanning mentioned in para. 9 will be during replacement,
*not* during definition!
In paragraph 10, the function-like macro itself is *not* similar
syntactically to a function *call*. I might replace "similar
syntactically" with "which will be invoked with a syntax similar".
The last sentence of para. 12 is hard to understand, until one
realizes that "the number of arguments" following merger" counts
"the variable arguments" as a single composite argument.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 89.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.3.3
Title: misc. wording #4
Detailed description:
In para. 2, I'd add "of a function-like macro" after "in the
replacement list".
The large parenthetical in the middle of para. 3 is quite
awkward; I'd make it a sentence in its own right,
non-parenthesized.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 90.
Category: Request for information/clarification
Committee Draft subsection: 6.8.3.3
Title: restrictions on constructed tokens?
Detailed description:
Are there *any* restrictions on the tokens that can be
constructed using ##, other than that universal character names
are out? (If there are restrictions, it probably wouldn't be hard
to state them in terms of translation phases, because that's
where they'd arise.)
"The resulting token is available for further macro replacement",
but not as a macro parameter name, right?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 91.
Category: Inconsistency
Committee Draft subsection: 6.8.3.3
Title: name of preprocessor concatenation operator
Detailed description:
The name "catenation operator" is used nowhere outside of
the examples.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 92.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.3.4
Title: misc. wording #5
Detailed description:
I would add the word "along" before "with all subsequent
preprocessing tokens of the source file", and I would set the
entire clause off with commas or by parenthesizing it.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 93.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.4
Title: line control syntax
Detailed description:
Shouldn't the syntax description in para. 4 should be
# line digit-sequence "s-char-sequence" [opt]
Or is the intent that an empty pair of quotes must remain if the
s-char-sequence is omitted? If so, shouldn't it be specified
whether the presumed source file name is set to null, or left
unchanged, in this case?
Also, could it be argued that #line should take a
q-char-sequence rather than s? I would think that the arguments
(e.g. possibly different treatment of \ in operating system
filenames) which caused the concept of q-char-sequence to be
introduced for #include would apply to #line as well.
(If there's any substance to this speculation, the category I've
given to this comment is wrong; it'd be a normative change.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 94.
Category: Other (comment)
Committee Draft subsection:
Title: #error wrinkles
Detailed description:
Is it worth a footnote to point out that
#error Hello, world!
will work, and that
#error "Hello, world!"
may get you more quotes in the output than you'd expected?
(Probably not.)
I've always thought that it would be nice to be clearer on
whether #error terminates translation, or perhaps to provide
two variants (one which does and one which doesn't), but now is
not the time to propose or discuss that.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 95.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.6
Title: #pragma musings
Detailed description:
I'd add "the compiler or" after "translation to fail or".
I'm also puzzled why it's stipulated that macro replacement is
*not* performed. By analogy with #include and #line, it seems
that it should be, and it might even be useful.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 96.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.8
Title: predefined macro names (wording)
Detailed description:
It would be clearer if "and shall expand as indicated" were added
after "shall be defined by the implementation."
I'm not sure why the word "presumed" appears in __FILE__'s
description, and not __LINE__'s. (Also, it might be worth
explicitly noting that both of these are affected by #line).
The parentheticals in the descriptions of __DATE__ and __TIME__
are significant enough that they should not be; I'd replace
"source file (a character string" with "source file: a character
string". Also, does the locale for the asctime function's
creating of month names need to be specified?
The word "shall" in para. 4 is odd. Presumably section 6.8.8 is
complete, and all predefined macro names simply *do*, by
observation, begin with two underscores. Is para. 4 trying to
constrain implementation extensions, or state future
directions? (In either case, the intent should be made clear.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 97.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.8
Title: typo #3
Detailed description:
There's an obvious formatting problem in para. 2.
PUBLIC REVIEW COMMENT #8
ISO/IEC CD 9899 (SC22N2620) Public Comment
Date: 1998-03-03
Author: Steve Summit
Author Affiliation: individual
Postal Address: 5812 15th Ave. NE
Seattle, WA 98105 USA
E-mail Address: scs@eskimo.com
Telephone Number: +1 206 522 7534
Fax Number: n/a
Number of individual comments: 114
-----------------------------------------------------------------
[begin boilerplate]
Before I dive in with my comments, I have several apologies and
disclaimers. I'm sorry that these comments are coming in at the
last minute, and that there are so many of them. Most of them,
at least, are editorial; I haven't made too many normative
suggestions. My main goal is to help keep the revised document
up to the high standards (for succinctness and accuracy) of its
predecessor.
I do not require feedback on any of these suggestions. I fully
understand (without rancor) that many of them will not be used;
the committee member(s) reviewing them need not feel guilty about
abandoning them, and need not apologize to me for doing so.
Where I have categorized a comment as "Request for information/
clarification", it is invariably a rhetorical question suggesting
that the Draft's wording may need to be clarified; I am not
requesting a personal response.
I apologize, too, for the naivete which I'm sure some of these
comments will display. I haven't kept up with the committee's
work as much as I'd like, and some of the issues which I've
expressed confusion about may well be straightforward. (On the
other hand, I'm not completely uninformed about C, as I have been
programming in it for about 20 years, maintaining the Usenet FAQ
list on it for the past 10, and teaching it for the past 5.)
Where I offer suggested new wording, I use two notations to
suggest alternatives: words in square brackets [] are optional,
and words between braces, separated by slashes
(e.g. {this/that/the other}) are alternatives to be chosen among.
I have scribbled more comments on my printout of the draft than
I have had time to present here before the deadline. If any
committee member is interested in, and somehow has time for,
polishing the wording of the document, I would be happy to pass
on more comments in the same vein (restricting them, of course,
to editorial changes, non-normative contribution, and requests
for clarification).
[end boilerplate]
I have suggested that the descriptions of several library
functions (e.g. fwprintf) be largely replaced with simpler
descriptions in terms of another function (in fwprintf's case, of
course, the basis function is fprintf). I have based my revised
descriptions on mechanical, word-based diffs of the draft wording
of the sections in question, and I would be happy to supply these
listings (or the program that generated them) to any committee
members who wish to verify that no non-accidental differences
have been overlooked.
I have divided my comments into three separate submissions.
This one (the second) covers section 7 and a few of the annexes.
The first one covers sections (clauses) 1 through 6, and the
third one contains editorial comments and suggestions of a
somewhat more nit-picky nature.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 1.
Category: Request for information/clarification
Committee Draft subsection: 7.1.1
Title: multibyte string definition
Detailed description:
"Shift sequence" is defined in paragraph 7 in terms of "multibyte
string", but it's not obvious what a multibyte string is.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 2.
Category: Request for information/clarification
Committee Draft subsection: 7.1.2
Title: careful definitions of standard macros
Detailed description:
Paragraph 5 says that implementors must be careful with the
definitions of standard object-like macros, but shouldn't the
same thing be said about function-like macros?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 3.
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.1.3
Title: new reserved identifiers
Detailed description:
Would it be at all practical to arrange that identifiers with
external linkage defined by this draft but *not* reserved by the
1989/1990 version, not be reserved unless their associated
headers are included? Otherwise, there are quite a number of
new "quiet changes." (As but one example, I suspect that many,
many windowing libraries already define a function wprintf for
formatted output into a window.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 4.
Category: Request for information/clarification
Committee Draft subsection: 7.1.3
Title: VPR #1
Detailed description:
The reference to "that context" in para. 2 is exceedingly vague,
and I'm not sure what is meant.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 5.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.1.4
Title: function definition of errno
Detailed description:
To avoid possible confusion, I recommend that the hypothetical
function suggested by footnote 134 be named __errno, or
_errno_function, or something. (Yes, I know, expansion of a
particular macro isn't recursive, but still.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 6.
Category: Other (comment)
Committee Draft subsection: 7.1.6
Title: multiply defined standard typedefs
Detailed description:
Does an explicit statement need to be made (e.g. in a footnote)
that "multiply defined" diagnostics for types such as size_t
are guaranteed not to occur even if several different headers
that define them are included?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 7.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.1.8
Title: more global caveats
Detailed description:
I would add another general stipulation to the "Use of library
functions" section, which although it is stated or implied
elsewhere, seems well worth placing up front:
When a function involves the copying of data, if the
destination object or array is not big enough to hold
the copied data, or if copying takes place between
objects that overlap [*], the behavior is undefined.
[* Footnote: since most library functions are not to
be used to copy between overlapping regions, their
pointer parameters are qualified with restrict.]
(If placed here, the wording about "copying takes place between
objects that overlap" can be removed from many individual
function descriptions. It must be the case that they don't all
need individual explicit statements, because not all of them have
it now.)
Also, to the parenthetical list of invalid values at the
beginning of para. 1, I would add "or a pointer to a non-string".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 8.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.2.1.1
Title: required information for assert's diagnostics
Detailed description:
The identifier __func__ has been added to the list in para. 2,
making the words "the latter" wrong unless the words "the current
function" are added somewhere before it.
An example implementation would be nice, too.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 9.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.3.1.3
Title: typo #1
Detailed description:
There's an extra "for" in the first sentence of para. 2.
Also, the comma after "set of characters" is unnecessary, and the
words "the following:" get in the way, and could be removed.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 10.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.3.1.7, 7.3.1.11
Title: misc. wording #1
Detailed description:
Like section 7.3.1.2, sections 7.3.1.7 and 7.3.1.11 should
reference footnote 146.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 11.
Category: Other (comment)
Committee Draft subsection: 7.3.2
Title: "corresponding" characters?
Detailed description:
Does the word "corresponding", as appearing in secs. 7.3.2.1 and
7.3.2.2, need any definition?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 12.
Category: Request for information/clarification
Committee Draft subsection: 7.4
Title: "suitable character constants"?
Detailed description:
What are the "suitable character constants" defined by macros in
<inttypes.h>, if not formatted I/O conversion specifiers?
Was this meant to say "suitable integer constants", e.g. INTMAX_C?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 13.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.4.5
Title: misdirected footnote?
Detailed description:
I doubt that para. 1 was meant to refer to footnote 151;
footnote 150, perhaps.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 14.
Category: Normative change to intent of existing feature
Committee Draft subsection:
Title:
Detailed description:
As I have said with respect to section 5.2.4.1, requiring all
implementations to support 65536-byte objects has potentially
serious effects on those with only 16 bits efficiently available.
I recommend requiring only 32767 as the minimum maximum values of
PTRDIFF_MIN, PTRDIFF_MAX, and SIZE_MAX.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 15.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.4.6
Title: typo #2
Detailed description:
A comma is missing after the word "performed" in the second
sentence of para. 1 in sec. 7.4.6.1, and in the same sentence
cut-and-pasted into secs. 7.4.6.2-7.4.6.4.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 16.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.5
Title: typo #3
Detailed description:
In para. 2, I believe it should say "*are* explained in
[section/subclause] 7.5.2.1."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 17.
Category: Request for information/clarification
Committee Draft subsection: 7.5.2.1
Title: localized characters or strings
Detailed description:
Since decimal_point, thousands_sep, et al. are described as
being "characters", it might be nice to explain why they are
declared as being multi-character strings. Is it so that they
can be multibyte sequences?
(Also, some descriptions, e.g. mon_decimal_point's, seem to be
missing the word "character" or "string".)
Are the members having to do with formatted monetary quantities,
and which do not explicitly specify "internationally" or
"locally", applicable to both, or just locally-formatted
quantities?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 18.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.5.2.1
Title: struct lconv: grouping and mon_grouping
Detailed description:
Paragraph 4 might rate a footnote pointing out that these are
integer values, *not* characters, that you want 3 or '\3' (not
'3') to specify a grouping of 3, and that the objects pointed to
by grouping and mon_grouping are *not* necessarily
null-terminated, nor are they in fact proper strings at all.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 19.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.6
Title: "the arithmetic"
Detailed description:
Two instances of "the arithmetic" in para. 1 read awkwardly,
because we and this arithmetic haven't been properly introduced.
I'd suggest replacing both with "floating-point arithmetic".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 20.
Category: Other (comment)
Committee Draft subsection: 7.6.2.5
Title: misc. wording #2
Detailed description:
I found the appearance of "bitwise OR" in the "Returns" clause
(para. 3) momentarily confusing, because I'd think of the function
as returning "the bitwise AND of the masks of currently set and
queried exceptions".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 21.
Category: Other (comment)
Committee Draft subsection: 7.6.3.2
Title:
Detailed description:
If it were like any of the other "set" functions in the standard
library, fesetround would return not only a nonzero value, but
the value of the previous mode. Would that be an option here?
(I know nothing of IEC 559, so perhaps not.)
Also, the description of the example refers to possible failure
of the setting of the rounding direction, but there are two
attempts to set; I'd say "...if setting the first rounding
direction" or "if the first set of the rounding direction".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 22.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.7
Title: weak xref
Detailed description:
"later" at the end of para. 1 is weak; why not say "in subclause
7.14.6" (if that's in fact where you had in mind)?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 23.
Category: Other (comment)
Committee Draft subsection: 7.7
Title: compile-time floating constant overflow?
Detailed description:
With respect to para. 4: As I have commented elsewhere, section
6.1.3.1 does not say as much as it might about floating-point
constant overflow.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 24.
Category: Request for information/clarification
Committee Draft subsection: 7.7
Title: Where is NAN?
Detailed description:
I can't find the description of the NAN macro. From reference
to it in sec. 7.7.11.12 and elsewhere, I learn that it might be
function-like, but I expected to see a formal statement to that
effect somewhere, probably in a distinct subclause for the NAN
macro. (If there is to be no such subclause, words could be
added to para. 5.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 25.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.7
Title:
Detailed description:
I think the word "that" is missing in para. 7: "...indicates that
the fma function...".
Describing FP_FAST_FMAF and FP_FAST_FMAL as simply "analogs" is a
little weak; if I wanted to be formal and pedantic I'd say they
"describe, in the analogous way, { the behavior of / whether }
the fmaf and fmal functions { are faster } than multiplies and
adds of float and long double operands, respectively.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 26.
Category: Other (comment)
Committee Draft subsection: 7.7
Title:
Detailed description:
In para. 9, a sentence or footnote relating DECIMAL_DIG to
FLT_DIG, DBL_DIG, and LDBL_DIG might be nice.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 27.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.7
Title: typo #4
Detailed description:
There may be a formatting problem in footnote 171.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 28.
Category: Request for information/clarification
Committee Draft subsection: 7.7.4.3
Title: atan(inf)?
Detailed description:
Should there be any mention of the result of taking the arc
tangent of an infinity, or are all such issues deferred to Annex F?
(I see that sec. F.9.1.3 covers just the case I asked about.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 29.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.7.6.8
Title: one to the 177?
Detailed description:
The attachment of footnote 177 is *particularly* awkward --
can't it be placed somewhere else, e.g. after "function"?
(Or was this a deliberate application of the teaching of
Nicholas Vanserg, who advised that "The other side of
the asterisk gambit is to use a superscript as a key to 14
a *real* footnote. The knowledge seeker reads that S is -36.7
calories and thinks `Gee what a whale of a lot of calories,'
until he reads to the bottom of the page, finds footnote 14
and says, `oh.'"? ["Mathmanship", as reprinted in A Stress
Analysis of a Strapless Evening Gown, Prentice-Hall, 1963,
ISBN 0-12-852608-7])
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 30.
Category: Request for information/clarification
Committee Draft subsection: 7.7.6.11
Title: partly perplexed by logb
Detailed description:
What does "in the format of x" mean?
I would have had an easier time understanding this function if it
were explicitly stated, up front, that the base with respect to
which the exponent is extracted is FLT_RADIX.
The second sentence is awkward; I might replace "normalized; thus
for" with "normalized. For".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 31.
Category: Other (suggestion)
Committee Draft subsection: 7.7.8
Title: erfc example?
Detailed description:
I don't have time to do the math or the implementation just now,
but wouldn't a lovely example involving erfc be a function
returning normally-distributed random numbers?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 32.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.7.9.3, 7.7.9.4
Title:
Detailed description:
The description in sec. 7.7.9.3 involves a gratuitous forward
reference. Why not interchange 7.7.9.3 and 7.7.9.4, and reword
nearbyint's description to "The nearbyint function is
{ similar / equivalent } to the rint function, differing only
in that..."?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 33.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.7.9.6
Title: llrint: one more notch less equivalent
Detailed description:
To the description in para. 2, I would add: ", and the result is
unspecified only if outside the range of long long."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 34.
Category: Other (comment)
Committee Draft subsection: 7.7.9.7, 7.7.9.8
Title:
Detailed description:
I notice that lround's return value is long int, and that round's
is not int but double. (There's a bit of invited confusion
lurking here.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 35.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.7.9.9
Title: llround: one more notch less equivalent
Detailed description:
To the description in para. 2, I would add: ", and the result is
unspecified only if outside the range of long long."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 36.
Category: Other (comment)
Committee Draft subsection: 7.7.10.3
Title: remquo: what's it for?
Detailed description:
remquo's definition strikes me as being very strange.
(Presumably there's some precedent in numerical work?)
3 seems woefully inadequate as the maximum guaranteed value for
n; I'd have expected 10 or 15.
Is the word "of" missing before "at least 3"?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 37.
Category: Other (comment)
Committee Draft subsection: 7.8.2.24
Title: cexp example
Detailed description:
It occurs to me that it'd be cute to give an example showing
that cexp(3.14159 * I) is pretty close to 1. (Or is it -1?
It's been too long...)
-----------------------------------------------------------------
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 38.
Category: Inconsistency
Committee Draft subsection: 7.10
Title: setjmp: macro or not?
Detailed description:
Sec. 7.10 para. 3 says that it's unspecified whether setjmp is a
macro, but sec. 7.10.1.1 refers to it (four times) as one.
(Also 3 times in sec. 7.10.2.1 para. 4.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 39.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.12.1.2
Title: va_arg *not* guaranteed to have type of next argument
Detailed description:
The first sentence of para. 2 could be very misleading!
I'd at least replace "argument" by "parameter", or perhaps
replace "has the type and value of the next... in the call"
with "fetches the value of the next argument in the call,
which is {assumed/asserted} to have type _type_."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 40.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.1
Title: what if I don't *want* any tmpnam's?
Detailed description:
The usage of "shall" with respect to TMP_MAX (in para. 3) is
incorrect. "shall be generated" should be replaced by "shall be
generatable" or simply "can be generated".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 41.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.1
Title: I/O function classification
Detailed description:
The descriptions of the wide-character input and output functions
claim they are described in "these subclauses", but of course
they're described nowhere in 7.13, but rather in 7.19.
The description of the byte input/output functions might say
"functions described in these subclauses that perform bytewise
input/output".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 42.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.2
Title: internal vs. external representations
Detailed description:
Paragraph 2 might be more explicit in noting that it's only
internal to the program that a text line consists of "zero or
more characters plus a terminating new-line character".
I'd add the words "internal to the program" (and perhaps even
refer to the "abstract machine") somewhere in the first sentence,
and add the word "external" before "host environment".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 43.
Category: Other (comment)
Committee Draft subsection: 7.13.5.2
Title: misc. wording #3
Detailed description:
Why is there a forward reference to 7.13.7.11?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 44.
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.13.5.3
Title: additional fopen modes
Detailed description:
I think that the behavior for mode strings other than those
listed should be implementation-defined, not undefined.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 45.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.1
Title: fprintf description
Detailed description:
Paragraph 3 should be rewritten to use these sentences, adapted
from 7.19.2.1, which are nice in and of themselves, and which
must be moved here if my suggestion (see comment 95) to have
7.19.2.1 refer to 7.13.6 is adopted.
The processing of conversion specifications is as if
they were replaced in the format string by strings
that are each the result of fetching zero or more
subsequent arguments and converting them, if applicable,
according to the corresponding conversion specifier.
The expanded string is then written to the output stream.
Section 7.9.2.1 uses present tense rather than 7.13.6.1's future
perfect, and I think the former is preferable. I'd change each
instance of "will be" to "is", "will begin" to "begins", "will
have" to "has", and "will contain" to "contains".
The subparagraph in sec. 7.13.6.2 para. 3 about size modifiers is
somewhat nicer; if I had time, I'd try to fold some of it into
7.13.6.1. Also, I'd change two instances of "the argument will
have been promoted... and its value shall be converted to" to
"...but its value shall be converted back to".
In the description of %g, I'd add "unless the # flag is
specified" after "Trailing zeros are removed from the fractional
portion of the result".
With respect to paragraph 8, presumably a pointer to an array of
integral type is as acceptable for %n as an array of char is
for %s.
Paragraph 14's wording is unnecessarily evocative of
sec. 5.2.4's, and reads badly here. I'd simply say
"An implementation shall be able to support at least 4096
characters as produced by any single conversion" or
"If the number of characters produced by any one conversion
exceeds 4096, the results are undefined."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 46.
Category: Inconsistency
Committee Draft subsection: 7.13.6.1
Title: printf %hhn ?
Detailed description:
The description of %n in para. 6 mentions the possibility of
%hhn, but the subparagraph about the n modifier in para. 3
does not.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 47.
Category: Other (comment)
Committee Draft subsection: 7.13.6.1
Title: printf format for complex
Detailed description:
Shouldn't there be a new printf (and scanf) format specifier for
the new complex types?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 48.
Category: Other (comment)
Committee Draft subsection: 7.13.6.1
Title: %a: any intellectual property problems?
Detailed description:
Using a formatted hexadecimal floating point representation is
an idea I've had for a long time but have never found time to
pursue; I'm delighted that the committee has introduced the %a
formats. However, I was dismayed a few years ago to hear that
IBM had somehow secured a patent on some variant of the same idea.
Is there any chance that all implementors will end up owing IBM
royalties for their (C9X-mandated) implementations of %a?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 49.
Category: Other (comment)
Committee Draft subsection:
Title: precision for %ls
Detailed description:
I suppose at one point it might have been an open question
whether a precision specifier within %ls should count wide
characters read from the source array or multibyte character
bytes written to the output stream. Since much code is thinking
more about the number of things being read from the array than
the number of things being written to the stream, and since the
count of bytes written ends up being so ambiguous (due to the
possibility, though denied, of partial multibyte sequences), I'd
say that it would have been better to specify the precision as
counting source wide characters, but I suppose it's too late now.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 50.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.1
Title: fprintf examples
Detailed description:
The word "this" in para. 16 is misleading; at first I assumed it
referred to the example I'd just read. It should either say
"the next example", or the examples should be numbered (as they
are in several other sections).
I found the second example nearly impossible to understand for
quite some time, until I realized that the notation "$0" was
intended to refer to one byte. (Yes, para. 16 can and should be
read to suggest otherwise, but I assumed that the $ was some
kind of shift sequence. We are, after all, talking about
multibyte sequences here.) I strongly suggest that a single
character be used, either @ or some non-ASCII glyph. (If there
was a taboo against using non-ASCII glyphs, the examples in sec.
7.13.6.2 have broken it.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 51.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.2
Title: fscanf wording
Detailed description:
Paragraph 3 is awkward; I'd add ", each of which is either: a
sequence of" between "zero or more directives" and "one or more
white-space characters".
There's an extra "or" between l and ll in the first word of the
third bullet item in para. 3.
The singular/plural games in para. 6 are distracting. Is the
reason for talking about characters plural being read from the
stream that it might take several of them to match one
(multibyte) character in the format string?
The statement that a result is placed in "the object pointed to
by the first argument following the format argument that has not
already received a conversion result" is cumbersome and awkward,
and seems as if it would be necessary only in the case of the
numerically tagged specifiers which I've heard rumor that System
V supports. Here, wouldn't it be easier just to talk about "the
next argument"? (The description of fprintf seems to get by
without any of this.)
In the description of %f et al., "constant" should be changed
to "number" and "string" should be changed to "sequence" (if for
no other reason than that these are the words that sec. 7.19.2.2
uses).
In the second subparagraph describing %[, a subparagraph break
before "the conversion specifier includes" would help.
In paragraph 14, the parenthetical should be changed to "(other
than %n, if any)" (for consistency with fwscanf sec. 7.19.2.2).
I don't find the first sentence of footnote 218 implied anywhere
in the Standard; I'd like to see it moved there.
Should the last sentence of the Returns section (para. 17)
say "...in the event of early matching or input failure"?
(If so, all of the descriptions of the *scanf and *wscanf
functions are affected.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 52.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.2
Title: fscanf examples
Detailed description:
Shouldn't the first paragraph of the examples get a new
paragraph number?
The parallelism in the description of example 1 is quite poor;
I'd replace "name will contain thompson\0" with "to the array
name the string "thompson"".
*Please* don't use feof in this Pascalish way in example 3!
Either use fscanf's return value somehow (since it's being
carefully saved, although currently not otherwise used), or
retain feof/ferror, but in a do/while loop.
The construction "the stdin stream contains" is awkward;
I'd say "If the following lines are available on stdin".
In (the awkwardly numbered) paragraph 18, "these" is again
misleading, and should be replaced with "the following".
Also, a one-character glyph such as @ or some non-ASCII
character should again be used instead of $0.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 53.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.5
Title: sprintf wording
Detailed description:
The placement of the clause "rather than to a stream" in para. 2
is awkward; it seems to attach to "the argument s", not "an array".
I'd reword it thus:
...except that the output is written to the string s,
rather than to a stream.
Also, I'd replace "returned sum" with "returned character count".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 54.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.6
Title: snprintf
Detailed description:
Hooray! This was the single greatest gaping need in the old
standard; I'm overjoyed to see it introduced here. I'd make the
first change suggested in comment 53 here too, though.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 55.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.7
Title: sscanf wording
Detailed description:
I'd reword the first sentence in para. 2 to end with
"...except that the input is read from the string s,
rather than from a stream."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 56.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.8 et al.
Title: vfprintf wording
Detailed description:
I'd change "(and possibly subsequent va_arg calls)" to
"(and possibly {modified/affected} by subsequent va_arg calls)".
If you agree, the change should be made to all of the v*printf
and v*scanf descriptions (including those in sec. 7.19.2).
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 57.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.10, 7.13.6.11
Title: typo $5
Detailed description:
In these sections (and a large number of other sections), the
sentence "If copying takes place between objects that overlap,
the behavior is undefined" should probably be removed." It's true
in more sections than it appears, but since it appears in so many
of them, someone might get the impression that it *doesn't* apply
where it doesn't appear. Rather than repeating it ad nauseum,
it should be stated up front in section 7.1.8, with the restrict
qualifiers in the individual function descriptions serving as a
reminder.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 58.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.12, 7.13.6.13, 7.13.6.14
Title: typo #6
Detailed description:
In each section, the word "function" is missing before "does not
invoke the va_end macro".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 59.
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.13.7.2
Title: array contents after fgets error
Detailed description:
I'd say that "indeterminate" is too strong a statement on the
undefinedness of the array contents after error. Realistically,
each element of the array will either contain some character
read before the error occurred, or some character that was there
before fgets was called. There seems no chance of a read error
causing the sorts of "taboo" bit patterns to occur that the term
"indeterminate" tends to suggest. I'd say that the array
contents after error ought to be defined as unspecified.
(If by chance you agree, the same change should presumably be
made to gets sec. 7.13.7.7, although anyone who call gets deserves
whatever he gets.)
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 60.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.7.3
Title: fputc in append mode
Detailed description:
In para. 2, near the existing wording "at the position indicated
by the associated file position indicator for the stream (if
defined)", don't some words need to be added along the lines of
"or at end-of-file if the stream was opened in "a" mode"?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 61.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.8.1
Title: fread "elements" undefined
Detailed description:
The descriptions of both fread and fwrite refer to "elements"
read or written, but this term (with this usage) is nowhere
defined. Use of it only suggests that the functions might
somehow treat array elements specially, e.g. by byte-swapping
the elements of an array of int appropriately (though how the
functions could ever know what swapping might be appropriate is
of course indeterminable).
Either the term "element" needs to be specifically defined as
"an array of unsigned char of size size", or the descriptions
need to be rewritten to use "bytes" instead of "elements".
For example:
The fread function reads, into the array pointed to by
ptr, up to nmemb*size bytes from the stream pointed to
by stream. The file position indicator for the stream
(if defined) is advanced by the number of bytes
successfully read. If an error occurs, the resulting
value of the file position indicator for the stream is
indeterminate. If the number of bytes successfully read
is not a multiple of size, the value of the last block
of size bytes is indeterminate.
Returns
The fread function returns the number of bytes
successfully read, divided by size, which may be less
than nmemb if a read error or end-of-file is encountered.
If size or nmemb is zero, fread returns zero and the
contents of the array and the state of the stream
remain unchanged.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 62.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.8.2
Title: fwrite "elements" undefined
Detailed description:
See the discussion under comment 61.
My suggested rewrite is
The fwrite function writes, from the array pointed to
by ptr, up to nmemb*size bytes to the stream pointed
to by stream. The file position indicator for the stream
(if defined) is advanced by the number of bytes
successfully written. If an error occurs, the resulting
value of the file position indicator for the stream is
indeterminate.
Returns
The fwrite function returns the number of bytes
successfully written, divided by size, which will be less
than nmemb only if a write error is encountered.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 63.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.9.1
Title: fgetpos description
Detailed description:
The file position indicator is of course no longer the only
information stored. I would change
...the current value of the file position indicator
for the stream pointed to by stream in the object...
to
...the current value of the file position indicator
and the mbstate_t object for the stream pointed to
by stream into the object...
or simply
...information about the current state of the stream
pointed to by stream, including the file position,
indicator [and the mbstate_t object], into the object...
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 64.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.9.2
Title: fseek wording
Detailed description:
In para. 2, "If a read or write error occurs" should be replaced
with "If an error occurs".
In para. 5, some words could be added (analogous to those in
7.13.9.3 para. 3) about a change from reading to writing, or
vice versa, now being possible for "r+", "w+", and "a+" streams.
-----------------------------------------------------------------
Comment 65.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.9.3
Title: fsetpos wording
Detailed description:
In para. 2, "If a read or write error occurs" should be replaced
with "If an error occurs".
In para. 3, I'd add ", resets the mbstate_t object for the
stream to that saved in *pos," before "and undoes any effects
of the ungetc function on the same stream".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 66.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.1.3, 7.14.1.4
Title: atol/atoll description discrepancy
Detailed description:
The descriptions (paras. 2) of atol and atoll are curiously
different. Is there any intent?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 67.
Category: Request for information/clarification
Committee Draft subsection: 7.14.1.5
Title: strtod description
Detailed description:
Do the words "but no floating suffix" in para. 3 apply to all
the bullets above? I assume so, in which case I would replace
the fragment with "In no case is a floating suffix expected or
accepted in the subject sequence."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 68.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.1.6, 7.14.1.7
Title: typo #7
Detailed description:
In both descriptions, "expect" should be replaced by "except that".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 69.
Category: Request for information/clarification
Committee Draft subsection: 7.14.1.7
Title: strtold precision
Detailed description:
Does the vague wording "similar to the strtod function"
adequately imply the function's presumably superior ability to
accurately reflect converted strings with large numbers of
significant digits?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 70.
Category: Request for information/clarification
Committee Draft subsection: 7.14.1.8
Title: strtol: null required?
Detailed description:
Paragraph 1 suggests that the final string includes the
terminating null character; does this mean that
char x[3] =3D "12x";
(void)strtol(x, NULL, 10);
is undefined?
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 71.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.1.8
Title: strtol wording
Detailed description:
For consistency with wcstol, in para. 3, add "(inclusive)" after
"base is between 2 and 36", change "10 to 35" to "10 through 35",
and add "and digits" before "whose ascribed values are less".
Also, add "subclause" before "6.1.3.2" in para. 5.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 72.
Category: Feature that should be included
Committee Draft subsection: 7.14.1.10
Title: strtoi
Detailed description:
Given that strtof has been added, I believe that strtoi should
be, as well.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 73.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.1.10
Title: strtoul wording (too much of)
Detailed description:
Given that strtoul's description is nearly identical to
strtol's, it could (and I think should) be replaced with
The strtoul function is equivalent to the strtol
function, except that the return value is type
unsigned long int.
That's really the *only* difference, other than the Returns
section, which would be given separately and explicitly, anyway.
My justification for the simplification is on general grounds
of parsimony, and also to make it easier for a reader to verify
that the two functions are, in fact, nearly identical.
I happen to have access to this draft in electronic form and to
a word-based diff program, but many readers will have neither.
(As a matter of fact, I think there should be a second and more
significant difference, namely that strtoul should not accept a
minus sign, but I guess it's too late for that now.)
If strtoul's text is not coalesced with strtol's, the exact same
comments as given above in comments 70 and 71 apply.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 74.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.2.1
Title: rand recommended practice
Detailed description:
Given that other sections have broken the ice on "Recommended
Practice" subsections, I would really love to see one for rand,
encouraging implementors to use an implementation (such as the
example in sec. 7.14.2.2) which allows users to take rand() % n
with decent results.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 75.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.3
Title: malloc recommended practice
Detailed description:
It would be nice to see some recommended practice here as well.
I would recommend three:
Whether or not free is explicitly called, all allocated
memory is reliably freed at program exit.
Space allocated by malloc is guaranteed to be available
to the program; no exceptions will result when the
program access the memory.
Whether freed memory is returned to an underlying
operating system and therefore made available to other
programs, or merely made available for future allocation
by the same program, is unspecified.
The second point obviously rules out "lazy allocation" schemes.
The third makes it explicit that returning freed memory to the
operating system is a valid possibility; I have heard it argued
that it somehow is not under the current C Standard.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 76.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.3.1
Title: calloc definition
Detailed description:
I think it is safer to define calloc as being equivalent to
malloc(nmemb * size)
rather than risking misinterpretations about "arrays" and
"objects" (see also comment 61). Also, the "all bits zero"
initialization could of course be succinctly defined in
terms of memset.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 77.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.3.4
Title: realloc description
Detailed description:
I'd say that the last sentence of the Returns section (para. 3)
should be moved to the formal description in para. 2, along with
an explicit statement that the former values of both ptr and
*ptr are then indeterminate.
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 78.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.4.1
Title: abort description
Detailed description:
The words "An implementation-defined form of the status
unsuccessful termination is returned to the host environment by
means of the function call raise(SIGABRT)" could be interpreted
as a recommendation to the programmer of how to get that result,
*as opposed to* whatever it is that abort does. I would change
"by means of the function call" to "as if by a call to".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 79.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.5
Title: searching/sorting wording
Detailed description:
In para. 3, it is presumably the implementation *of qsort* which
may reorder elements of the array, not the comparison function
of the preceding sentence (nor bsearch).
I would use plural in para. 4:
When the same objects (consisting of size bytes,
irrespective of their current position in the array)
are passed more than once...
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 80.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.5
Title: qsort/bsearch example
Detailed description:
An example might be nice:
After declaring
char *sarray[100];
int pstrcmp(const void *p1, const void *p2)
{
return strcmp(*(char * const *)p1, *(char * const *)p1);
}
and after filling in the array sarray with 100 pointers to
strings, the call
qsort(sarray, 100, sizeof(char *), pstrcmp)
will sort them, and the call
char *p =3D bsearch("test", sarray, 100, sizeof(char *), pstrcmp);
will search for the string "test".
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 81.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.6.2
Title: div wording
Detailed description:
I would replace "of the division" with "resulting from the
division", and I might add "If denom is 0 or" before "if the
result cannot be represented."
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 82.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.15
Title: centralized non-overlap wording
Detailed description:
If the undefinedness of copying between overlapping regions
is asserted just once, up fron