JTC1/SC22/WG14
N849
Disposition of U.S. Comments Report for CD 9899, Ballot Document N2620
Document number: J11/98-048
All responses are marked with a response code whose meaning is indicated
in the list of response codes at the end of this document.
All responses marked E indicate Editorial and have been forwarded to an
editorial review group for their consideration.
------------------------------------------------------------------------
C9x Public Comment Log
------------------------------------------------------------------------
1. US0001 1998-01-21 Tribble 'complex' not always a keyword
Source characters not allowed as UCNs
2. US0003 1998-02-05 Tribble Useless __STDC__ macro
3. US0004 1998-02-10 Tribble argv ptr changeability
4. US0005 1998-02-11 Tribble NULL macro type
5. US0006 1998-02-13 Tribble isprint('\t')
6. US0007 1998-02-24 Josey Century handling in strftime()
7. US0009 1998-03-04 Summit Submission 1 of 3 (97 items)
8. US0009 1998-03-04 Summit Submission 2 of 3 (114 items)
9. US0010 1998-03-04 Summit Submission 3 of 3 (42 items)
10. US0011 1998-03-04 Eggert intro comment + 13 items
11. US0012 1998-03-03 Tribble Bitfield widths
-----------------------------------------------------------------
US PUBLIC REVIEW COMMENT #1
------------------------------------------------------------------------
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.
Response Code: DA
The identifiers "_Complex" and "_Imaginary" are always
keywords now.
-----------------------------------------------------------------
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?
Response Code: Q
The current specification allows for efficient lexing.
-----------------------------------------------------------------
US PUBLIC REVIEW COMMENT #2
------------------------------------------------------------------------
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.)
Response Code: BS
While the committee sympathizes with your concern, unfortunately,
the standard cannot comment on near-conforming or extended
implementations.
------------------------------------------------------------------------
US PUBLIC REVIEW COMMENT #3
------------------------------------------------------------------------
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.
Response Code: NC
There was unsufficient interest by committee members to make
this change.
------------------------------------------------------------------------
US PUBLIC REVIEW COMMENT #4
------------------------------------------------------------------------
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 = NULL; // Should be 0
char ch = NULL; // Should be '\0' or NUL
memset(p, NULL, sz); // Should be '\0' or 0
if (ch > NULL) ... // Should be '\0' or 0
The 'NULL' macro ought to represent a pointer value, not simply a zero
value.
[2]
Many implementations could define 'NULL' thus:
#define NULL ((void*)0)
which meets the requirements above. A few implementations use a
representation other than "all bits zero" to represent a null pointer,
so they could define 'NULL' as something like this:
#define NULL ((void*)0x80000000) // ala IBM CICS
The definition above does not restrict the type of 'NULL' to anything
other than a pointer type; it is not required to be 'void*' per se,
but could be whatever type the compiler vendor deems appropriate. For
example:
#define NULL __null // Vendor A
#define NULL ((__notype*)0) // Vendor B
In these cases, '__null' and '__notype' are implementation-specific
reserved words with special meanings. (It is assumed that in both
cases the type of 'NULL' is "implementation-specific pointer type".)
Response code: NC
There was insufficient interest by committee members to make
this change. This and related issues have been debated a number
of times and if one were starting from scratch, NULL (or some
spelling thereof) would be a keyword that could only be used in
pointer contexts. However, at this late stage, we think it
inappropriate to require that NULL expand to an expression of
some pointer type, there is simply too much code that expects
NULL to expand to some form of zero-valued integer expression.
------------------------------------------------------------------------
PUBLIC REVIEW COMMENT #5
------------------------------------------------------------------------
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')==0, while Microsoft Visual C defines
isprint('\t')!=0.) Most seem to agree that the "nongraphic" = characters
of 5.2.2 are control characters (so that iscntrl('\t') is true). But
'\t' appears to be a special case; yes, it's a control character, but
is it also a printable character (just like ' ')?
This should be clarified in the standard. (I personally think that
isprint('\t') should be false; after all, if it's true, shouldn't
isprint('\f') and others also be true? But I think that would be a
mistake.)
Perhaps the use of the word "nongraphic character" (in 5.2.2) should be
replaced with something more exact, such as "control character". And
perhaps the definitions of the iscntrl(), isprint(), and isgraph()
functions could be clarified so that it is impossible for some
character code X to be both iscntrl(X)!=0 and isprint(X)!=0, i.e.,
the "control" and "printable" (or "graphic") characters are defined as
mutually exclusive sets.
(As I recall, Clive D. W. feather wrote something on this before, but
apparently it didn't make it into the draft.)
Response Code: IF
-----------------------------------------------------------------
PUBLIC REVIEW COMMENT #6
-----------------------------------------------------------------
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]
Response Code: Y
Proposal accepted
------------------------------------------------------------------------
PUBLIC REVIEW COMMENT #7
-----------------------------------------------------------------
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.
Response Code: Q
Unlike examples and footnotes (which are for information only),
recommended practice subsections are a normative part of the
standard. However, they contain no requirements, and so do not
affect the conformance status of an implementation.
-----------------------------------------------------------------
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.
Response Code: Q
The translations limits indicate certain minimum requirements.
Implementors are encouraged to provide as few contraints as
possible with respect to maximum size and complexity
-----------------------------------------------------------------
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".
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: DA
The term is now clearly deprecated.
-----------------------------------------------------------------
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.
Response Code: DA
The term is now clearly deprecated.
-----------------------------------------------------------------
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)".
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: Q
Since the term `linked' is in widespread use in other
language standards and is well understood by practicing
programmers, the committee feels no compulsion to define
this term, especially since that term has no C-specific
conotations.
-----------------------------------------------------------------
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.
Response Code: SD
-----------------------------------------------------------------
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.)
Response Code: EN
-----------------------------------------------------------------
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?
Response Code: Q
This is currently implictly unspecified and the committee
has chosen to leave it that way.
-----------------------------------------------------------------
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.)
Response Code: EN
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: EN
-----------------------------------------------------------------
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).
Response Code: AL
-----------------------------------------------------------------
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.)
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: M
The committee recognizes your concern, but chose to leave
the new minimum limits as they are. Note that for a very
large array, it is permitted that the difference between
pointers to elements in that array not be representable
by the type ptr_diff_t. This is disussed in the Rationale
Document.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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...".
Response Code: AL
-----------------------------------------------------------------
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"?
Response Code: Q
No
-----------------------------------------------------------------
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.
Response Code: Q
The term `variably modified' is defined in the draft
and the committee believs it is used consistently.
-----------------------------------------------------------------
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.)
Response Code: AL
-----------------------------------------------------------------
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.)
Response Code: PC
Since two adjacent members of a structure can have padding
between them, no guarantee exists that a storage alignment
with complex types exist.
-----------------------------------------------------------------
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?
Response Code: Q
Yes it does; the committee sees no other interpration.
-----------------------------------------------------------------
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.)
Response Code: EN
-----------------------------------------------------------------
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".
Response Code: AL
-----------------------------------------------------------------
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.)
Response Code: Q
Constraint violation if value is not in range. The
constarint being violated is the one in 6.1.3.
-----------------------------------------------------------------
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.
Response Code: N
The committee sees no reason to disallow very large character
sets. In any event, programs can already contain character
constants of the form '\x0000...0000n', where ... represents
an unlimited number of zeros and n represents some hexadecimal
number.
-----------------------------------------------------------------
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.
Response Code: SD
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: N
The committee sees no compelling reason to require
implementors to document how they handle such characters.
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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".
Response Code: SD
-----------------------------------------------------------------
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".
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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.)
Response Code: AL
-----------------------------------------------------------------
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.)
Response Code: Q
Yes, from malloc.
-----------------------------------------------------------------
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.)
Response Code: EY
The committee agrees that the term is unnecessarily misleading
and that an appropriate editorial change will be made. In
any event, the example makes it quite clear as to the format
of the resulting string given a function name.
-----------------------------------------------------------------
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).
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: Q
The committee acknowledges your suggestion is cleaner,
but it offers no new value, so the current words have
been retained.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: AL
-----------------------------------------------------------------
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".
Response Code: EY
-----------------------------------------------------------------
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."
Response Code: EY
-----------------------------------------------------------------
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?)
Response Code: Q
This issue was resolved in the committee's response
to Defect Report #81. The behavior is implementation-defined,
draft subsection is 6.3.7.
-----------------------------------------------------------------
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 >= q yields 1 if p == q and is undefined if p != q.
(I presume this is the intent.)
Response Code: M
You have misread the draft. p!=q yields false. An example
of undefined behavior in p>=q is when p and q are not
pointing into elements or members of the same array,
structure, or union.
-----------------------------------------------------------------
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."
Response Code: SD
-----------------------------------------------------------------
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 = b + c;
if(a != 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.)
Response Code: N
See 6.2.1.7, paragraph 2.
-----------------------------------------------------------------
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.
Response Code: EN
-----------------------------------------------------------------
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 .
Response Code: SD
-----------------------------------------------------------------
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))..."
Response Code: CE
-----------------------------------------------------------------
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= E2 is equivalent
to the simple assignment expression E1 = E1 op (E2), except
that the lvalue E1 is evaluated only once.
Response Code: CE
-----------------------------------------------------------------
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?
Response Code: Q
Yes, a diagnostic is required.
-----------------------------------------------------------------
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.
Response Code: Q
The committee believes the existing words to be clear.
-----------------------------------------------------------------
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.)
Response Code: Q
The committee believes the list to be complete.
-----------------------------------------------------------------
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".
Response Code: CE
-----------------------------------------------------------------
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.)
Response Code: PR
The keyword "complex" does not default to the type
"double complex" because Fortran default "COMPLEX" is
single precision and this could lead to confusion.
-----------------------------------------------------------------
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.
Response Code: Y
The Committee has adopted this.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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 = &c;
where c was a const object, a later assignment by
the caller to *p (e.g. *p2 = 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.
Response Code: AL
-----------------------------------------------------------------
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.
Response Code: Q
Part A: Since "p1" is associated with the outermost block
and is assigned a value based on a restrict-qualified
pointer from the inner block, the behavior is undefined.
Therefore the last half of paragraph 4 causes undefined
behavior in cited example.
Part B: The following change eliminates the word "attention" and
clarifies the intent.
Change the last two sentences of para. 5 in 6.7.3.1 from:
A reference to a value means either an access to or a
modification of the value. During an execution of B,
attention is confined to those references that are actually
evaluated.
to read:
An access to a value means either fetching it or modifying it;
expressions that are not evaluated do not access values.
and delete the associated footnote. Finally, the term "visible"
is a well defined term in the Draft (6.2.1).
Part C: The exception is "the execution of B2 shall end prior to
the assignment" which is further clarified in the second
half of EXAMPLE 4.
Part D: An object consists of a contiguous sequence of bytes, so
there is only 1 array object (6.2.6.1).
-----------------------------------------------------------------
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.
Response Code: EN
-----------------------------------------------------------------
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.
Response Code: E
-----------------------------------------------------------------
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.)
Response Code: EN
ISO style is to omit ``subclause'' except for top-level
subclauses.
-----------------------------------------------------------------
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".
Response Code: EN
-----------------------------------------------------------------
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.
Response Code: Q
The first sentence permits local statics. The second
sentence probibits local static VLAs, but permits local
static pointers to VLAs. See Example 4, Array Declarators.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: E
-----------------------------------------------------------------
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."
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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".
Response Code: SD
-----------------------------------------------------------------
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?
Response Code: Q
It is permitted to reinitialize the same element or
member of an array, structure or union. All such
initializers must be evaluated in lexical order.
See paragraph 14.
-----------------------------------------------------------------
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?
Response Code: Q
The committee believes so and existing implementations
do so.
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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.)
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: N
The Committee discussed this proposal but decided
against it.
-----------------------------------------------------------------
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.
Response Code: EN
-----------------------------------------------------------------
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)".
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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?
Response Code: Q
Yes, you are correct.
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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).
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: N
The words are as was intended. A macro can now have an empty
argument. For example:
#define M1(...)
M1()
results in 1 empty argument in the call. Similarly,
#define M2(x, ...)
M2(a,)
results in 2 arguments in the call, the second of which
is empty. Note that M2 cannot be called using
M2(a)
M2 must be called with at least one more argument that
is specified in the macro's definition, as required by
the current draft.
-----------------------------------------------------------------
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.
Response Code: E
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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?
Response Code: Q
There are no restrictions.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: EN
The case where the s-char-sequence is completely omitted is
covered in the previous paragraph.
-----------------------------------------------------------------
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.
Response Code: Q
The existing words say that the resulting text includes
the user-specified text, allowing implementations to add
quotes already.
Over the years there has been some discussion about
providing something like #warning that issues a message
and continues; however, this suggestion has never gathered
sufficient interest.
-----------------------------------------------------------------
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.
Response Code: EY
Some standard pragmas contain identifiers like ON and OFF,
which are likely to be defined as macros.
-----------------------------------------------------------------
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.)
Response Code: E
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
PUBLIC REVIEW COMMENT #8
-----------------------------------------------------------------
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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?
Response Code: Q
This is covered in 7.1.4, para. 1.
-----------------------------------------------------------------
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.)
Response Code: N
The functions to which you refer were added some
years ago by Amendment 1, they are not new in this
revision of the standard.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: CE
-----------------------------------------------------------------
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?
Response Code: N
It is clear that a typedef name cannot be redefined,
so the implementation must define names such as size_t
once only even if multiple headers capable of defining
that name are included. It has to be made to work by the
implementor such that the programmer need take no special
action.
-----------------------------------------------------------------
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".
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: SD
isblank and iswblank were not approved and should not have
appeared in the draft.
-----------------------------------------------------------------
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.
Response Code: EN
-----------------------------------------------------------------
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?
Response Code: CE
-----------------------------------------------------------------
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?
Response Code: SD
The draft has been reworked in this area.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: N
A 16-bit implementation can support 64K-sized objects.
The type ptrdiff_t need not be able to store all pointer
differences, however, size_t can, as can the macros.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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."
Response Code: EY
-----------------------------------------------------------------
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?
Response Code: Q
Apparently some cultures use multiple characters.
The inconsistency regarding the use of character
and string is a hold-over from the previous standard.
Editorial changes have been to accomodate some of
your suggestions.
-----------------------------------------------------------------
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.
Response Code: CE
Note that grouping and mon_grouping *are* strings and require
proper termination.
-----------------------------------------------------------------
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".
Response Code: EY
-----------------------------------------------------------------
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".
Response Code: Q
The committee thinks the text is clear on this issue.
-----------------------------------------------------------------
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".
Response Code: PA and CE
Part A: Although this approach could work, it conflicts
with too much prior art in this area.
Response: PA
Part B: The committee believes it is clear enough that
the first fesetround implements the "set" which
is being checked for failure and the second
fesetround implements the "restore".
Response: CE
-----------------------------------------------------------------
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)?
Response Code: EN
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: Q
The "NAN" macro is described in paragraph 5 and is
_not_ a function-like macro. The example in the
"nan" function description shows a string literal
argument to the "strtod" function. This is not
directly related to the "NAN" macro.
-----------------------------------------------------------------
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.
Response Code: EY and CE
-----------------------------------------------------------------
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.
Response Code: Q
DECIMAL_DIG has been moved from math.h to float.h
and the relationship of these macros has been made
clearer.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: Q
You have it right.
-----------------------------------------------------------------
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])
Response Code: EY
-----------------------------------------------------------------
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".
Response Code: AL and CE
Part A: Replacing "the format of x" with "floating-point
format" to be consistent with function "rint".
Response: AL
Part B: Current woding is clear enough.
Response: CE
Part C: Current woding is clear enough.
Response: CE
-----------------------------------------------------------------
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?
Response Code: NI
You are correct that it would be a good example - time
permitting.
-----------------------------------------------------------------
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..."?
Response Code: AL
-----------------------------------------------------------------
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."
Response Code: AL
-----------------------------------------------------------------
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.)
Response Code: PA
Too much prior art in this area.
-----------------------------------------------------------------
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."
Response Code: AL
-----------------------------------------------------------------
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"?
Response Code: AL
-----------------------------------------------------------------
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...)
Response Code: NI
Example is not needed.
-----------------------------------------------------------------
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.)
Response Code: Q
References to macro is 7.13.1.1 do not supercede that
in 7.13. It is a style issue in the library section
that the draft refers to the macro X or the function
X, rather than just X.
-----------------------------------------------------------------
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_."
Response Code: AL
-----------------------------------------------------------------
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".
Response Code: EY
-----------------------------------------------------------------
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".
Response Code: EY
-----------------------------------------------------------------
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".
Response Code: CE
-----------------------------------------------------------------
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?
Response Code: E
-----------------------------------------------------------------
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.
Response Code: N
-----------------------------------------------------------------
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."
Response Code: AL
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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?
Response Code: Q
These were intentionally not provided, to print a
complex number you must extract and print its real
and imaginary parts indidually.
-----------------------------------------------------------------
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?
Response Code: Q
We are not aware of any intellectual property ownership
issues in this regard.
-----------------------------------------------------------------
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.
Response Code: BE
Yes, it is.
-----------------------------------------------------------------
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.)
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: E
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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".
Response Code: AL
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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."
Response Code: AL
-----------------------------------------------------------------
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).
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: AN
-----------------------------------------------------------------
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".
Response Code: EY
-----------------------------------------------------------------
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.)
Response Code: N
Indeterminate indicates the same level of reliability
as does unspecified. In the interest of retaining the
same definition as ISO 9899:1990, no change will be
made.
-----------------------------------------------------------------
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"?
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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...
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: E
-----------------------------------------------------------------
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".
Response Code: AL
-----------------------------------------------------------------
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?
Response Code: E
-----------------------------------------------------------------
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."
Response Code: E
-----------------------------------------------------------------
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".
Response Code: EY
-----------------------------------------------------------------
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?
Response Code: E
The descriptions of strtof and strtold have been
combined into a single subsection resulting in
the text in question's being removed.
-----------------------------------------------------------------
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] = "12x";
(void)strtol(x, NULL, 10);
is undefined?
Response Code: Q
Yes; the argument must be a string.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: N
strtof was added to support correctly rounded results
for float that would not otherwise occur with strtod.
Since strtol and strtoul subsume completely int and
unsigned int conversion, the committee sees no need
to provide strtoi and strtoui.
-----------------------------------------------------------------
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.
Response Code: EY
-----------------------------------------------------------------
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.
Response Code: EN
-----------------------------------------------------------------
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.
Response Code: EN
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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.
Response Code: CE
-----------------------------------------------------------------
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".
Response Code: EN
-----------------------------------------------------------------
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...
Response Code: EY
-----------------------------------------------------------------
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 = bsearch("test", sarray, 100, sizeof(char *), pstrcmp);
will search for the string "test".
Response Code: EN
-----------------------------------------------------------------
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."
Response Code: SD
-----------------------------------------------------------------
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 front (see comment 7), it could
be removed from the individual subsections of this section.
Response Code: AN
-----------------------------------------------------------------
Comment 83.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.15.5.7
Title: typo #8
Detailed description:
A period is missing at the end of para. 2.
Response Code: EY
-----------------------------------------------------------------
Comment 84.
Category: Feature that should be included
Committee Draft subsection: 7.15.5.8
Title: safer strtok
Detailed description:
Following the precedent set by wcstok (sec. 7.19.4.5.7), there
should really be a strtok variant (some implementations call it
strtok_r) which accepts a pointer to the pointer storage to be
used between calls.
Response Code: N
When wcstok was added, it was given more capability
than existed in strtok. However, the committee has
decided against provided equivalent support in
an extended version of strtok.
-----------------------------------------------------------------
Comment 85.
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.16.1
Title: tm_extlen default value
Detailed description:
Following the Internet rule of "Be conservative in what you
send, liberal in what you accept", I believe that tm_extlen
should be specified as being 0 if tm_ext is a null pointer
(para. 5). Leaving it unspecified buys nothing, and only
invites needless errors. (If this change is made, the lists
in Annex K will of course have to be updated.)
Response Code: N
-----------------------------------------------------------------
Comment 86.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.16.2.3
Title: mktime verbiage
Detailed description:
Paragraphs 5 and 6 repeat too much of paragraphs 3 and 4.
Response Code: EY
-----------------------------------------------------------------
Comment 87.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.16.2.4
Title: mkxtime wording
Detailed description:
In paragraph 2, "into account of" should be either "into account"
or "account of". Also, "of struct tmx" could be usefully added
at the end of that sentence.
In paragraph 3, "include the effects" should probably be
"including the effects".
There is no Returns section.
Response Code: AL
-----------------------------------------------------------------
Comment 88.
Category: Other (comment)
Committee Draft subsection: 7.16.3.5
Title: misc. wording #4 (zonetime)
Detailed description:
More precisely, if the implementation cannot determine the
relationship between the implementation's time and the requested
zone. (Para. 2.)
(Also, the pronoun "that" in para. 3 is vague.)
Response Code: EY
-----------------------------------------------------------------
Comment 89.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.16.3.6
Title: strftime description
Detailed description:
The reason for the bracketed member names in the list of
conversion specifiers in para. 2 should be explained.
(Presumably they are the ones containing "values contained
in the structure" relevant to that specifier.) For %x and %X,
"[all specified in 7.6.1]" would more fully be "[all fields
specified in subclause 7.6.1]".
For %Z, I presume that the time zone name or abbreviation may be
locale-specific.
Response Code: EY
-----------------------------------------------------------------
Comment 90.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.18.2.1
Title: misc. wording #5
Detailed description:
I can't parse the first sentence of para. 2. I think what it's
trying to say is
For wide characters corresponding to regular characters,
and/but with the exception of..., each of the following
functions...
Response Code: E
-----------------------------------------------------------------
Comment 91.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.18.2.1.1
Title: typo #9
Detailed description:
Th first word of para. 2 is misspelled.
Response Code: EY
-----------------------------------------------------------------
Comment 92.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.18.2.1.3
Title: typo #10
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.
Response Code: SD
isblank and iswblank were not approved and should not have
appeared in the draft.
-----------------------------------------------------------------
Comment 93.
Category: Request for information/clarification
Committee Draft subsection: 7.18.2.1.0
Title: iswspace definition
Detailed description:
Saying "none of iswalnum, iswgraph, or iswpunct" seems redundant,
because I believe iswgraph tests for the union of iswalnum and
iswpunct. Also, the relationship (inclusive or exclusive) to
iswcntrl is not mentioned.
Response Code: EN
-----------------------------------------------------------------
Comment 94.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.1
Title: misc. wording #6
Detailed description:
In paragraph 10, there are now *two* functions for wide-string
date and time conversion.
Response Code: EY
-----------------------------------------------------------------
Comment 95.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.2.1
Title: fwprintf wording (too much of)
Detailed description:
Given that fwprintf's description is nearly identical to
fprintf's, it could (and I think should) be replaced with
The fwprintf function is equivalent to the fprintf
function (see section 7.13.6.1), except that:
the format string pointed to by fmt is a wide
character string;
the various characters expected in the format
string, and the characters written to the output
stream, are all wide characters;
wherever 7.13.6.1 refers to n-char-sequence,
fwprintf uses n-wchar-sequence;
[though there's no difference?]
for the %c format specifier, if no l qualifier
is present, the int argument is converted to a
wide character as if by calling btowc, and the
resulting wide character is written;
for the %c format specifier, if an l qualifier
is present, the wint_t argument is converted
to wchar_t and written; and
for the %s format specifier, the behavior/
description is [as now described in the working
draft section 7.19.2.1].
I believe that this list is complete, especially if the changes
suggested in comment 45 are incorporated.
See also my comment 73 for additional justification for this
change. (I might also point out that section 7.19.5 already uses
this sort of wording to define wcsftime in terms of strftime, so
there's a precedent.)
If fwprintf's text is not coalesced with fprintf's:
the extra sentence at the end of para. 2 should be
discarded;
the discrepancy (noted in comment 46) with respect to %hhn
should be rectified; and
the first paragraph under "Recommended practice" should be
numbered.
Also, I believe the example should be omitted; it is so similar
to fprintf's example that it serves no useful purpose.
Response Code: EN
-----------------------------------------------------------------
Comment 96.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.2.2
Title: fwscanf wording (too much of)
Detailed description:
Given that fwscanf's description is nearly identical to
fscanf's, it could (and I think should) be replaced with
The fwscanf function is equivalent to the fscanf
function (see section 7.13.6.2), except that:
the format string pointed to by fmt is a
wide character string;
the various characters expected in the
format string, and the characters read from
the input stream, are all wide characters;
the (optional) maximum field width in a
conversion specifier specifies a count of
wide characters;
a directive that is an ordinary wide character
[in the format string] is expected to match a
wide character read from the input stream;
input white-space characters (to be skipped in
response to white-space directives and before
conversion specifiers other than %[, %c, and %n)
are as specified by the iswspace function;
{ input performed by the %d and %i specifiers
is converted as if by a call to the wcstol
function / the input expected by the %d and %i
specifiers is of the same format as that expected
for the subject sequence of the wcstol function };
{ input performed by the %o, %u, and %x specifiers
is converted as if by a call to the wcstoul
function / the input expected by the %o, %u, and %x
specifiers is of the same format as that expected
for the subject sequence of the wcstoul function };
{ input performed by the %a, %e,, %f and %g
specifiers is converted as if by a call to the
wcstod function / the input expected by the %a, %e,
%f and %g specifiers is of the same format as that
expected for the subject sequence of the wcstod
function };
for the %[, %c, and %s format specifiers, the
behavior/description is [as now described in the
working draft section 7.19.2.2, or try to coalesce
if you like].
I believe that this list is complete.
See also my comment 73 for additional justification for this
change.
If fwscanf's text is not coalesced with fscanf's:
several of my suggestions from comment 51 apply
analogously;
the typo in the description of %[ should be fixed
("f no l qualifier is present"); and
the missing period at the end of %%'s description
should be supplied.
Also, I believe the examples should be omitted; they are so
similar to fscanf's examples that they serve no useful purpose.
Response Code: EN
-----------------------------------------------------------------
Comment 97.
Category: Other (comment)
Committee Draft subsection: 7.19.2.5
Title: swprintf confusion
Detailed description:
It was wrong to have given swprintf its current functionality
without naming it snwprintf or swnprintf, and the confusion is
compounded now that snprintf's return value is specified so
differently.
Response Code: CC
The committee agrees. We decided to `do it correctly'
with the new function and that does not match the
older function.
-----------------------------------------------------------------
Comment 98.
Category: Other (comment)
Committee Draft subsection: 7.19.3.1
Title: fgetwc description
Detailed description:
Is there anything to be said about the orientation (byte/wide)
of the stream? (Ditto, I suppose, for fputwc.)
Response Code: Q
The committee thinks not.
-----------------------------------------------------------------
Comment 99.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.3.9
Title: typo #11
Detailed description:
A close parenthesis is missing after the second instance of
"pointed to by stream".
Response Code: EY
-----------------------------------------------------------------
Comment 100.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.4.1.1
Title: wcstod wording (too much of)
Detailed description:
Given that wcstod's description is nearly identical to
strtod's, it could (and I think should) be replaced with
The wcstod function is equivalent to the strtod
function (see section 7.14.1.5), except that:
where strtod expects certain characters
(including those referred to in subclause
6.1.3.1), wcstod expects the corresponding
wide characters;
initial white-space characters (to be skipped)
are as specified by the iswspace function;
wherever 7.14.1.5 refers to n-char-sequence,
fwprintf uses n-wchar-sequence;
[though there's no difference?]
and
paragraphs 6 and 7 are swapped :-).
I believe that this list is complete.
See also my comment 73 for additional justification for this
change.
Response Code: EN
-----------------------------------------------------------------
Comment 101.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.4.1.1
Title: n-wchar-sequence definition
Detailed description:
Is the definition of n-wchar-sequence any different from
n-char-sequence? Also, these two sequences are missing from
Annex B.
Response Code: Q
Although the abstract semantics are the same, the types of
the characters are different (one is narrow, the other is
wide). They don't appear in annex B because they are not
part of the language syntax.
-----------------------------------------------------------------
Comment 102.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.4.1.4
Title: wcstol wording
Detailed description:
Given that wcstol's description is nearly identical to
strtol's, it could (and I think should) be replaced with
The wcstol function is equivalent to the strtol
function (see section 7.14.1.8), except that:
where strtol expects certain characters
(including those referred to in subclause
6.1.3.2), wcstol expects the corresponding
wide characters;
the various characters expected in the input
string are all wide characters; and
initial white-space characters (to be skipped)
are as specified by the iswspace function.
I believe that this list is complete.
See also my comment 73 for additional justification.
Response Code: EN
-----------------------------------------------------------------
Comment 103.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.4.1.6
Title: wcstoul wording
Detailed description:
Given that wcstoul's description is nearly identical to
strtoul's, it could at the very least be replaced with
The wcstoul function is equivalent to the strtoul
function (see section 7.14.1.10), except that:
where strtoul expects certain characters
(including those referred to in subclause
6.1.3.2), wcstoul expects the corresponding
wide characters;
the various characters expected in the input
string are all wide characters; and
initial white-space characters (to be skipped)
are as specified by the iswspace function.
I believe that this list is complete.
On the other hand, wcstoul could be defined even more succinctly
in terms of wcstol, analogous to my comment 73 (q.v. for more
justification for this suggestion).
Response Code: EN
-----------------------------------------------------------------
Comment 104.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.4.6
Title: typo #12
Detailed description:
I believe a comment is missing after "affected by locale" in
para. 1.
Response Code: EY
-----------------------------------------------------------------
Comment 105.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.7
Title: misc. wording #7
Detailed description:
The parameter name ps appears in para. 4 out of a clear sky.
It could be introduced in para. 2: "...take as a last argument
a pointer, ps, to an object...".
Response Code: EY
-----------------------------------------------------------------
Comment 106.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.7.3.1
Title: typo #13?
Detailed description:
In paragraph 3, should the word "or" be inserted before "a value"?
Response Code: EY
-----------------------------------------------------------------
Comment 107.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.7.3.2
Title: typo #14?
Detailed description:
In paragraph 4, ion the subparagraph for positive return,
I believe the comma should be a semicolon.
Response Code: EY
-----------------------------------------------------------------
Comment 108.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.19.7.4.1
Title: mbsrtowcs specification
Detailed description:
Should the src parameter have type const char * restrict * restrict?
In para. 2, should there be a comma after "pointed to by src"?
If an encoding error occurs, is the pointer pointed to by src
unchanged, unspecified, or undefined? (Para. 4).
These comments all apply to wcsrtombs (sec. 7.19.7.4.2), as well.
Response Code: EN
-----------------------------------------------------------------
Comment 109.
Category: Editorial change/non-normative contribution
Committee Draft subsection: Annex B
Title: n-char-sequence in syntax summary?
Detailed description:
As I've mentioned elsewhere, neither n-char-sequence
(sec. 7.14.1.5) nor n-wchar-sequence (sec. 7.19.4.1.1) appear.
Response Code: EN
-----------------------------------------------------------------
Comment 110.
Category: Editorial change/non-normative contribution
Committee Draft subsection: Annex C
Title: printf sequence points
Detailed description:
Section 7.13.6 implies that "there is a sequence point after the
actions associated with each specifier."
Response Code: EY
-----------------------------------------------------------------
Comment 111.
Category: Request for information/clarification
Committee Draft subsection: Annex E
Title: misc. wording #8
Detailed description:
What are FLT_EVAL_METHOD and FLT_ROUNDS doing there between
paragraphs 2 and 3?
Response Code: E
-----------------------------------------------------------------
Comment 112.
Category: Editorial change/non-normative contribution
Committee Draft subsection: Annex I
Title: typo #15?
Detailed description:
My copy of Unicode spells Cyrillic with two l's.
Response Code: EY
-----------------------------------------------------------------
Comment 113.
Category: Editorial change/non-normative contribution
Committee Draft subsection: Annex J
Title: warnings about warnings
Detailed description:
I would *not* say that warnings about converting "a pointer to
void to a pointer to any type other than a character type" are
common. (It's C++ that requires casts on every call to malloc,
not C.)
Warnings about functions with return statements with and without
expressions should no longer be required, given that changes to
sec. 6.6.6.4 (I believe) make these errors now.
I'd say it's poor to warn about unrecognized pragmas.
Response Code: E
-----------------------------------------------------------------
Comment 114.
Category: Editorial change/non-normative contribution
Committee Draft subsection: K.2
Title: not-so-undefined behavior
Detailed description:
Many of the bullet items in section K.2 are strange, and do
not seem to correspond to language in the draft Standard.
Here are a few:
The first character of an identifier is a digit (6.1.2).
[not possible, I'd say]
The same identifier is used more than once as a label in the
same function (6.1.2.1).
[not possible, I'd say]
A trap representation is produced by a side effect that
modifies any part of the object by an lvalue expression that
does not have character type. (6.1.2.8.1).
[may be okay, but I can't parse it]
The whole-number and fraction parts of a floating constant
are both omitted (6.1.3.1).
The period and the exponent part of a decimal floating
constant are both omitted (6.1.3.1).
Conversion between two pointer types produces a result that
is incorrectly aligned (6.2.1.3).
[6.2.1.3 is about floating-point types; this identical text
appears 6 more bullets down under 6.2.2.3]
Non-integer operands are used with a bitwise operator (6.3).
Response Code: EY
-----------------------------------------------------------------
PUBLIC REVIEW COMMENT #9
-----------------------------------------------------------------
-----------------------------------------------------------------
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 5.1.1.1
Title: misc. wording #1
Detailed description:
The clause ", in this International Standard" in para. 1 is
extremely awkward, and invites being read as the place where
program text, source files, and/or preprocessing files are
stored. Rather than trying to reword or relocate the clause,
I'd say it could simply be omitted.
Response Code: AL
-----------------------------------------------------------------
Comment 2.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.2.5
Title: misc. wording #2
Detailed description:
In the last sentence of para. 3, I'd omit the word "just".
Response Code: EY
-----------------------------------------------------------------
Comment 3.
Category: other (comment)
Committee Draft subsection: 6.1.2.5
Title: misc. wording #3
Detailed description:
The keyword `signed' appears out of a clear sky in para. 14,
somewhat awkwardly.
Response Code: EN
-----------------------------------------------------------------
Comment 4.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.2.5
Title: misc. wording #4
Detailed description:
It seemed to me that para. 19 belonged next to para. 14.
Response Code: AL
-----------------------------------------------------------------
Comment 5.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.2.1.1
Title: confusing wording on promotable types
Detailed description:
In para. 3, the words "the original type" have a mildly vague
antecedent. They really mean "the type being used instead"
(although that wording's obviously worse).
Response Code: CE
-----------------------------------------------------------------
Comment 6.
Category: Other (comment)
Committee Draft subsection: 6.2.2.2
Title: misc. wording #6
Detailed description:
I don't think there are any contexts where "a void expression is
required"; the likely candidates (secs. 6.3.17, 6.6.3, and
6.6.5.3) all merely say that the expression (of presumably any
type) is "evaluated as a void expression".
Response Code: EY
-----------------------------------------------------------------
Comment 7.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.2.2.3
Title: misc. wording #7
Detailed description:
In para. 7, "pointed-to type" (i.e. with an added hyphen) might
read more clearly.
Response Code: EY
-----------------------------------------------------------------
Comment 8.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.1.1
Title: misc. wording #8
Detailed description:
Please make sure (by using \^, or whatever) that the underscores
are distinct in the section head, table of contents, index, etc.,
as they are in the body of para. 1.
Response Code: EY
-----------------------------------------------------------------
Comment 9.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.2.1
Title: misc. wording #9
Detailed description:
The antecedent of the word "that" in "that in turn" is ambiguous.
(Is it "the results", the "array of five ints", or "the
expression x[i][j]"?)
Response Code: EY
-----------------------------------------------------------------
Comment 10.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.2.2
Title: misc. wording #10
Detailed description:
Paragraph 10's point would be made more strongly if it used
the words "actual arguments".
Response Code: EY
-----------------------------------------------------------------
Comment 11.
Category: Request for information/clarification
Committee Draft subsection: 6.3.3.3
Title: misc. wording #11
Detailed description:
Is "the integral promotion" singular now?
Response Code: EY
-----------------------------------------------------------------
Comment 12.
Category: Other (comment)
Committee Draft subsection: 6.3.6
Title: misc. wording #12
Detailed description:
I have to say, those two parentheticals in paras. 2 and 3 sound
pretty retarded, and don't seem to add much.
Response Code: EN
-----------------------------------------------------------------
Comment 13.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.4
Title: misc. wording #13
Detailed description:
I'd find footnote 85 a bit clearer with the word
"initialization" or "initializing" inserted before "expression".
Response Code: CE
-----------------------------------------------------------------
Comment 14.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.2.1
Title: misc. wording #14
Detailed description:
The words "of this" in para. 10 are awkward, and the pronoun has
no antecedent. I'd simply delete both words.
Response Code: EY
-----------------------------------------------------------------
Comment 15.
Category: Other (comment)
Committee Draft subsection: 6.5.2.1
Title: misc. wording #15
Detailed description:
A "flexible array member"?? (Para. 15.) I'm sorry, but I
suspect that most of us will continue to call it "the struct
hack" (or perhaps, "the new, legitimate struct hack").
Response Code: CC
-----------------------------------------------------------------
Comment 16.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.5.1
Title: misc. wording #16
Detailed description:
I might add "(which shall also not be modified)" at the end of
the sentence ending in "to point to another object" in the
example paragraph 3.
Response Code: AL
-----------------------------------------------------------------
Comment 17.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.6
Title: misc. wording #17
Detailed description:
The word "desired" in para. 2 seems wrong; I might suggest
"necessary". Also, the second sentence is easy to misread --
it really needs parentheses for grouping, i.e. "a declaration
for (a function or an object) of that type". I'm not sure how
to fix it, although part of the problem is simply the use of
both indefinite articles.
Response Code: EY
-----------------------------------------------------------------
Comment 18.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.7
Title: misc. wording #18
Detailed description:
The construction "specifies the type specified" in para. 2 is
awkward, but I don't know how to fix it. I might add the word
"along" between "shall be evaluated" and "with the typedef name".
The construction "declared in ordinary declarators" reads badly;
I'd at least change it to "declared in ordinary declarations" or
"declared by ordinary declarators".
Response Code: AL
-----------------------------------------------------------------
Comment 19.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.8
Title: misc. wording #19
Detailed description:
Paragraph 3 might read better with the alternatives interchanged:
The type of the entity to be initialized shall be
an object type that is not a variable length array type
or an array of unknown size.
I observe (though this probably doesn't ever rate a footnote)
that "object type that is not a variable length array type"
perforce includes arrays of known size.
In paragraph 6, is it obvious that "any nonnegative value is
valid" means only that it is syntactically valid, but that the
implementation might complain if a large value caused an object
to be too large?
Response Code: CE
-----------------------------------------------------------------
Comment 20.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.8
Title: misc. wording #20
Detailed description:
"that member" in para. 13 has a vague referent.
Should the word "below" in para. 15 be "herein"?
In para. 20, "these rules" might be better than just "the rules".
Response Code: E
-----------------------------------------------------------------
Comment 21.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.8
Title: misc. wording #21
Detailed description:
In example 7, towards the end, I would change "that is
initialized" to "and initializes it".
Response Code: EY
-----------------------------------------------------------------
Comment 22.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.6.4.2, 6.6.6.1
Title: misc. wording #22
Detailed description:
The first sentence of section 6.6.4.2 para. 1 is pretty awful,
but I'm afraid I don't have any suggestions for fixing it.
Section 6.6.6.1 para. 1 isn't much better. In both sections,
removing the words "to a... statement... in the block (or an
enclosed block)" might help; these words add much to the
cumbersomeness and seemingly nothing to the meaning (i.e. my
reading of the paragraphs is the same with those words removed).
Response Code: SD
-----------------------------------------------------------------
Comment 23.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.6.6.1
Title: misc. wording #23
Detailed description:
Example 1 is a heroic attempt to make an example realistic, for
once, but I'm afraid it was lost on me. Jumping into blocks is
a capability that clearly exists but is just as clearly almost
always a bad idea; given those facts, I just couldn't motivate
myself to wrap my brain around the tortured justification, nor
(I think) would my understanding of the issue of jumping into
blocks have changed if I had. I'd omit that example.
Response Code: EN
-----------------------------------------------------------------
Comment 24.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.1
Title: misc. wording #24
Detailed description:
The verb tenses in paragraph 10 are inconsistent. The three
instances of "shall be" clash with other instances of "are",
and should all be changed to "is" (unless the are's are changed
to shall's as well).
Response Code: EY
-----------------------------------------------------------------
Comment 25.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.7.1
Title: misc. wording #25
Detailed description:
At the end of example 1, I'd say that the second form *does* not.
Response Code: EY
-----------------------------------------------------------------
Comment 26.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8
Title: misc. wording #26
Detailed description:
In the syntax description, I'd define `lparen' as "a left
parenthesis character not preceded by any whitespace."
Response Code: EY
-----------------------------------------------------------------
Comment 27.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.8.3.2
Title: misc. wording #27
Detailed description:
In para. 1, I might replace "parameter" with "parameter name".
In para. 2, I might replace "between" with "within" or "among".
Response Code: CE
-----------------------------------------------------------------
Comment 28.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.1.2
Title: misc. wording #28
Detailed description:
In para. 3, I'd replace "included" with "searched for".
The exception for <assert.h> in para. 4 is imperfectly worded.
What it's trying to say, of course, is that the effect of
including <assert.h> multiple times depends on the instantaneous
definition of the NDEBUG macro.
Response Code: EY
-----------------------------------------------------------------
Comment 29.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.1.6
Title: misc. wording #29
Detailed description:
In the description of offsetof, strictly speaking, what we need
is that the member-designator *and type* are such that...
Response Code: EY
-----------------------------------------------------------------
Comment 30.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.4
Title: misc. wording #30
Detailed description:
At the end of para. 2, I'd say that *many* of these names *will*
denote the same type!
Response Code: EN
-----------------------------------------------------------------
Comment 31.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.4.4
Title: misc. wording #31
Detailed description:
With respect to footnote 152, I'm not sure how typical it is for
printf and scanf format strings to be different; in my own work,
I try to keep them identical. I'd replace "typically" with "in
the general case", and "are required" with "may be required".
Response Code: EY
-----------------------------------------------------------------
Comment 32.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.7.3.5
Title: misc. wording #32
Detailed description:
I'd say that "doesn't" in footnote 176 should be spelled out.
Response Code: EY
-----------------------------------------------------------------
Comment 33.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.3
Title: misc. wording #33
Detailed description:
In para. 7, I'd say "As initially opened, the standard error stream..."
I think the word "nor" in the second bullet in para. 9 is wrong.
Response Code: E
-----------------------------------------------------------------
Comment 34.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.5.4
Title: misc. wording #34
Detailed description:
I'd delete the word "successfully" in para. 3 -- failure to close
the file unsuccessfully (or at all) is ignored, too!
Response Code: EY
-----------------------------------------------------------------
Comment 35.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.1
Title: misc. wording #35
Detailed description:
I'd add the word "character after % in the description of the %%
specifier in para. 6. (For consistency with sec. 7.19.2.1, if
nothing else.)
Response Code: EY
-----------------------------------------------------------------
Comment 36.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.6.1
Title: misc. wording #36
Detailed description:
Towards the end of the description of %[, I'd change "the next
right bracket wide character is the matching right bracket that
ends the specification" to "the next following right bracket wide
character".
Response Code: EY
-----------------------------------------------------------------
Comment 37.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7/13/6/8
Title: misc. wording #37
Detailed description:
In footnote 219, I'd change "invoke" to "do invoke", and "after
the return" to "in the caller becomes".
Response Code: CE
-----------------------------------------------------------------
Comment 38.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.7.8
Title: misc. wording #38
Detailed description:
putc takes two arguments, so I would change "so the argument" in
para. 2 to "so that argument".
Response Code: EY
-----------------------------------------------------------------
Comment 39.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.13.7.11
Title: misc. wording #39
Detailed description:
I'd change "The pushed-back characters" in para. 2 to either
"Pushed-back characters" or "The pushed-back character".
(I wonder why the plural was used at all, since multiple
characters of pushback are of course not guaranteed.)
Response Code: EY
-----------------------------------------------------------------
Comment 40.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.1.5
Title: misc. wording #40
Detailed description:
In para. 4, two instances of "like a" are awkward; I'd replace
both with "as would be a".
Response Code: EN
-----------------------------------------------------------------
Comment 41.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.2.2
Title: misc. wording #41
Detailed description:
I would change "a new sequence" to "the sequence" and
"the sequence of pseudo-random numbers shall be repeated"
to "the same sequence...".
Response Code: EN
-----------------------------------------------------------------
Comment 42.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.14.5.2
Title: misc. wording #42
Detailed description:
In para. 4, I would say "in the resulting sorted array".
Response Code: EY
-----------------------------------------------------------------
PUBLIC REVIEW COMMENT #10
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: none
Title: Introduction to my comments on Draft C9X
Detailed description:
Here are some comments on Draft C9X from the point of view of a GCC
implementer. In the terminology of the standard, GCC is a
freestanding compiler, so I'm restricting most of these comments to
the compiler proper. I will ignore many of the changes in the
standard, as they affect the underlying C library but require no
changes to GCC itself. My current expertise is mostly in the
preprocessor area, so I'll focus in that area.
However, I've also implemented part of the <time.h> section of the GNU
C library, so I'll also comment on changes in that area.
Response Code: CC
-----------------------------------------------------------------
Comment 2.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 5.1.1.2, 5.2.1, 6.1.2, Annex I
Title: Universal Character Names (UCNs): the basic model is wrong
Detailed description:
Background
Draft C9X proposes a new notation (e.g. \u098a or \U0000098A) for
including arbitrary ISO 10646 (Unicode) characters in identifiers,
strings, and comments. They work as follows:
* In translation phase 1, each multibyte source file character is
replaced by the corresponding UCN. This occurs very early, even
before trigraph replacements.
* In translation phase 5 (just after preprocessing), UCNs in char
constants and string literals are converted to the execution
character set.
* Some UCNs are valid in identifiers, but not others. E.g.
\u098a (BENGALI LETTER UU) is valid, but
\u2110 (SCRIPT CAPITAL I) is not valid.
Problems
Here are some problems with UCNs as they appear in the current draft.
* The current draft assumes that source file characters can be
transliterated to Unicode and back again without loss of
information.
This assumption is incorrect and unrealistic. For example,
ISO-2022-JP
<ftp://ftp.isi.edu/in-notes/rfc1468.txt> cannot
be converted to Unicode without losing information.
As a trivial example, ISO-2022-JP distinguishes between `ESC
( B' (which switches to ASCII) and `ESC ( J' (which switches to
JIS-Roman); but Unicode discards the distinction between ASCII
and JIS-Roman for most characters, as it unifies most of the
characters in the two sets. This means that the C9X draft
effectively disallows the correct handling of ISO-2022-JP in
string literals; an ISO-2022-JP string that contains `ESC ( J'
is not guaranteed to contain the same `ESC ( J' after being
translated to Unicode and back again.
I believe that EBCDIC has a similar problem, as there are
multiple representations of `[' in EBCDIC but only one in
Unicode.
* The use of \u collides with common usage in include directives.
For example, `#include "h\ufeed.h"' must be treated
equivalently to `#include "[email protected]", where @ is Unicode character
FEED (ARABIC LETTER WAW ISOLATED FORM). This is not what the
programmer likely intended, and C9X must not require this weird
sort of case-folding.
* The current draft requires that the implementation maintain
translation tables from the source and execution character set
to Unicode, in order to properly stringize strings. This
requirement is unrealistic. Many environments are not using
Unicode yet, and do not have such tables. This problem is
particularly acute for portable compilers like GCC, as there
is no portable standard for accessing such transliteration tables.
* The current draft silently changes behavior when stringizing =
strings
that contain multibyte characters. For example, if @ represents
the Unicode character with code FEED (ARABIC LETTER WAW ISOLATED =
FORM),
then
#define str(s) #s
printf("\t# of <%s> is <%s>\n", "@", str("@"));
outputs something like this:
# of <@> is <"\ufeed">
whereas with C89 the program would output
# of <@> is <"@">
Clearly the C89 behavior is what is expected.
* The current draft precludes a simple implementation that simply
treats characters with the top bit on as letters. Such an
implementation supports popular encodings like UTF-8 and EUC
without having to know what the encoding is. However, the
current draft requires that the implementation convert each
character to Unicode, which means the implementation must
laboriously check for encoding errors, transliterate to and
from Unicode, and the like. It also means the user must
configure the compiler correctly, to specify which encoding is
desired.
* The list of UCNs allowed in identifiers is arbitrary and weird.
Although the standard seems to allow an implementation to permit
almost all UCNs in identifiers, this is not made clear.
Suggestion
Reword the standard so that UCNs are translated to the source
character set in translation phase 1, and are never seen again.
Allow an implementation-defined set of source characters in
identifiers, using the existing Annex I as a guideline.
More specifically, in Section 5.1.1.2 phase 1 change from:
Any multibyte source file character not in the basic
source character set is replaced by the
universal-character-name that designates that multibyte
character.
to:
Any universal-character-name is replaced by a corresponding
character in the source character set. The relation between
universal-character-names and source characters, and the choice
if more than one corresponding source character exists, is
implementation-defined.
In Section 5.1.1.2 phase 4, remove the following sentence, which
is no longer needed:
If a character sequence that matches the syntax of a
universal-character-name is produced by token concatenation
(6.8.3.3), the behavior is undefined.
In Section 5.1.1.2 phase 5, remove the phrase ``and
universal-character-name''.
Remove the existing constraints from Section 5.1.1.2; they are
no longer needed. Replace them with the following constraint:
In translation phase 1, a universal-character name must
correspond to a character in the source character set.
In section 6.1.2, uniformly replace universal-character-name with
other-source-character-letter. Add a production
other-source-character-letter:
A source character letter that corresponds to
one of the characters mentioned in Annex I
Response Code: SD
Please see WG14 N837.
-----------------------------------------------------------------
Comment 3.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 5.1.1.2, 6.8.3.4, 6.8.6, 6.8.9, etc.
Title: standard pragmas should be declarations
Detailed description:
Background
Draft C9X has added six pragmas, which can appear only where
declarations can appear. These pragmas do not act as preprocessing
directives in any way, except that they are themselves not subject
to further preprocessing.
These pragmas are inconvenient to explain and use, since they act
much like declarations -- e.g. they have scope -- but they do not
appear in the language grammar proper, nor can the user easily
write a parameterized macro that expands to such a pragma.
The rules for where these pragmas can appear are complicated and
confusing. In a system where the preprocessor is a separate
program, these pragmas will require special treatment in the
compiler's lexer and parser, since they do not follow the usual
rules for tokenization; e.g. newline is significant.
Suggestion
Instead of
#pragma STDC FP_CONTRACT ON
use the syntax
pragma STDC FP_CONTRACT ON;
Allow standard-pragmas like this to appear at the topmost level,
or at the start of a compound statement, by modifying the grammar for
external-declaration and compound-statement in the obvious way.
You can make `pragma' a keyword if you like, but this isn't
necessary.
Once this change is made, there's no need for the pragma operator;
it can be removed.
Response Code: PR
-----------------------------------------------------------------
Comment 4.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 6.8, 6.8.3, 6.8.3.1
Title: The name of __VA_ARGS__ should be specifiable by the user
Detailed description:
Background
Draft C9X introduces a new syntax for macros with varying arguments, =
e.g.
#define debug(file, format, ...) fprintf(file, format, __VA_ARGS__)
Common existing practice, as with GCC, is to use a syntax where
the varying arguments are named, e.g.
#define debug(file, format, args...) fprintf(file, format, args)
Suggestion
Allow GCC's syntax for macros with varying arguments.
This is an extension to the syntax proposed in draft C9X.
It is more readable, as it lets programmers give useful mnemonic
names to the varying argument lists, thus improving readability
and maintainability.
Response Code: PR
-----------------------------------------------------------------
Comment 5.
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.7.14
Title: Builtin relational operators should be allowed to be quiet
Detailed description:
Background
Draft C9X requires that A<B raise an exception if either A or B is
a NaN, and provides new functions, e.g. isless(A,B) if quiet =
comparisons
(i.e. comparisons that do not raise exceptions) are desired.
Existing practice (e.g. GCC, Sun C) is that A<B is quiet.
The rule of draft C9X is therefore a change to existing practice,
which will break many programs that operate correctly now.
Suggestion
Allow the builtin relational operators to be either noisy or quiet,
at the implementer's option. Provide new functions, e.g.
isless_noisy(A,B), which are guaranteed to be noisy.
Response Code: BC
IEC 559 arithmetic requires such comparisons to raise
an exception if either operand is a NaN. However, the
comparison does not, by default, cause a trap. Instead
it just sets the exception flag and continues executing.
-----------------------------------------------------------------
Comment 6.
Category: Request for information/clarification
Committee Draft subsection: 6.1.2.4
Title: a compiler should be able to reject jumping past a VLA allocation
Detailed description:
Background
Section 6.1.2.4 paragraph 3 says:
If the object is variably modified and the block is entered by
a jump to a labeled statement, then the behavior is undefined.
It's not clear from this language that a translator is allowed to
reject such programs. If the jump is never executed,
the undefined behavior will never occur. Existing practice (as
in GCC) is to reject such programs at compile-time.
Suggestion
Make it clear that existing practice is allowed by changing the
above wording to:
If the object is variably modified and the block contains a labeled
statement that is a target of a goto statement outside the block,
then the behavior is undefined.
Response Code: SD
The Committee has made significant changes in this area.
-----------------------------------------------------------------
Comment 7.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 6.1.2.8.1
Title: two identical objects can compare not equal
Detailed description:
Background
The text says
Two values with the same object representation shall compare
equal, but values that compare equal might have different object
representations.
This is not true for NaNs; two NaNs with the same object =
representation
must compare not equal.
Suggestion
Replace ``Two values'' with ``Two integer values''.
Response Code: AL
-----------------------------------------------------------------
Comment 8.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 6.5.2.1
Title: can't go two past the end of an array
Detailed description:
Background
Paragraph 15 says
If this array would have no elements, then it behaves as if it
has one element, but the behavior is undefined if any attempt
is made to access that element.
This makes it sound like you can address one past this unaccessible
element, which presumably is not intended.
Suggestion
Append ``, or to calculate the address just past that element''
to that sentence.
Response Code: EY
-----------------------------------------------------------------
Comment 9.
Category: Request for information/clarification
Committee Draft subsection: 6.4
Title: casts in sizeof VLA
Detailed description:
Background
The text says
Cast operators in an integer constant expression shall only
convert arithmetic types to integer types, except as part of an
operand to the sizeof operator.
However, with the advent of VLAs, sizeof may need to be evaluated
when applyed to a varying length array type. Are arbitrary casts
allowed inside such sizeof expressions that are within integer
constant expressions? Presumably not, but this needs to be
clarified.
Response Code: Q
An expression involving a VLA is not an integer expression;
therefore, arbitrary casts are allowed on such expressions
when used in the operand of the sizeof operator.
-----------------------------------------------------------------
Comment 10.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.3.2
Title: unsuffixed decimal no longer defaults to unsigned
Detailed description:
Background
Draft C9X says that an unsuffixed decimal number is of type int,
long int, or long long int, depending on its value. However, C89
says that its type is int, long int, or unsigned long int.
This can break conforming programs. For example, on a host with
64-bit longs and long longs, the constant 9223372036854775808 is a
valid unsigned long constant in C89, but is prohibited by C9X.
Suggestion
Add a footnote describing this problem, containing the last
sentence of the ``Background'' section above.
Response Code: EN
-----------------------------------------------------------------
Comment 11.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 5.1.2.3
Title: inconsistency in comment in 5.1.2.3 example 5
Detailed description:
The last comment in example 5 starts ``not equivalent of'';
it should be ``not equivalent to''.
Response Code: EY
-----------------------------------------------------------------
Comment 12.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 5.2.1, 5.2.1.2
Title: UCNs not allowed in identifiers?
Detailed description:
Section 5.2.1 paragraph 3, last sentence, says:
If any other characters are encountered in a source file
(except in a character constant, a string literal, a header name,
a comment, or a preprocessing token that is never converted to a
token), the behavior is undefined.
This seems to contradict the standard's intent of allowing national
characters in identifiers.
Similar problems are in 5.2.1.2 paragraph 2.
Response Code: EY
-----------------------------------------------------------------
Comment 13.
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.16.3.4
Title: localtime should be allowed to return NULL
Detailed description:
Background
Draft C9X. as well as C89, requires that localtime return a nonnull
value.
gmtime can return a null pointer, but localtime cannot.
Common existing practice is for localtime to return null if the
argument cannot be represented or is considered to be an illegal
value. For example, if the argument is negative, many =
Microsoft-based
implementations return null. Another example: if time_t is 64 bits
but int is only 32 bits, and if a very large time_t value is passed
to localtime, the resulting year cannot be stored in the tm_year
member; in such cases, localtime returns null in many
implementations.
Suggestion
Allow localtime to return a null pointer if the broken-down time
cannot be represented, or if the input time_t value is invalid.
Similarly for zonetime, assuming zonetime is retained (see comment
14 below).
Response Code: AL
Changes along the line of your proposal have been made.
-----------------------------------------------------------------
Comment 14.
Category: Feature that should be removed
Committee Draft subsection: 7.16
Title: changes to <time.h> need a lot of work and should be withdrawn for =
now
Detailed description:
Background and comments
Draft C9X introduced a new time struct tmx, new macros
_NO_LEAP_SECONDS and _LOCALTIME, and new functions mkxtime,
zonetime, and strfxtime.
These new functions seem to be an invention of the committee;
they are not based on existing practice, and in some cases
even ignore longstanding existing practice. The new functions
do not address many of the common problems observed with the
C89 primitives, notably with mktime. Nor do they add much
functionality.
For example, a common extension to C, now required by POSIX.1, are
reentrant versions of localtime, gmtime, etc. This fills a
genuine need, but it's not addressed by draft C9X.
There are also other genuine needs that are not addressed; just
look at, say, the harsh words about mktime expressed by the author
of the tide-calculation program XTide in its source code
<http://www.universe.digex.net/~dave/files/xtide-1.6.2.tar.gz>.
Draft C9X addresses few of the needs expressed by this author.
Here are some more detailed comments on technical shortcomings
in this area.
Section 7.16.1 paragraph 3.
The tm_zone member is an integer number of minutes. However,
common practice (e.g. SunOS 4.x, BSD/OS, Linux) is to have a
member named tm_gmtoff that is a long number of seconds. This
is required for proper support of POSIX.1, which lets the user
specify UTC offset to the second; it is also required for
proper support of historical applications. For example, the
UTC offset of Liberia was 44 minutes and 30 seconds until May
1972, and any program running on, say, Linux with the TZ
environment variable set to "Africa/Monrovia" cannot operate
correctly with if the UTC offset is required to be a multiple
of 60 seconds.
The tm_ext and tm_extlen members are an unprecedented kludge
in the standard library spec. This is not C++! If the
specification for struct tmx is incomplete, this suggests that
the editorial work is not done and this type should be
withdrawn from the standard.
Section 7.16.2.3 paragraph 4.
Here, draft C9X added the following new specification for mktime:
If the call is successful, a second call to the mktime
function with the resulting struct tm value shall always
leave it unchanged and return the same value as the first
call. (*)
This specification is reasonable for mkxtime, but for mktime
it requires changes to existing practice in a way that breaks
existing software. Existing software often assumes that
tm_isdst is either negative, 0, or 1; C89 does not guarantee
this, but it is common existing practice, so software that
makes this assumption is portable in practice.
Unfortunately, specification (*) cannot be satisfied without
either adding hidden members to struct tm (which breaks binary
compatibility) or by stuffing more information into tm_isdst
(which breaks the programs described above).
Granted, programs shouldn't assume that a positive tm_isdst
is 1, but it's very common in POSIX.1 programs to see
expressions like `tzname[tm->tm_isdst]', and these expressions
won't work if tm_isdst contains large values.
Section 7.16.2.4 paragraph 3.
If tm_zone was _LOCALTIME, and if tm_isdst is preposterous
(e.g. negative, or INT_MAX), this specification is unclear
about what to do. The comments in 7.16.2.6 don't help much.
Section 7.16.2.6 paragraph 1.
The specification for tm_isdst does not allow for negative
daylight-saving time. I don't know of any historical practice
for this, but POSIX.1 allows it, and implementations that
support POSIX.1 have to allow for it.
Section 7.16.2.6 paragraph 2.
The limits on ranges for struct tmx members are unreasonable.
Common existing practice, for example, is to invoke mktime
with a large value for tm_sec to compute a time stamp at some
distance from the POSIX.1 epoch. If int and long are the same
size, this runs afoul of the new restriction in this section,
which limits tm_sec to one-eighth of the potential range.
With this limitation I cannot even use mktime to compute
today's date on my Unix host from today's time_t value!
The other limits are also unnecessary. A well-written mktime
should work in the presence of arbitrary values in struct
tm members; similarly for mkxtime.
Section 7.16.2.6 paragraph 3.
There are so many errors in this section that it is hard to
determine what is intended. But from what I can tell, the
intent is wrong. For example, it seems to be saying that if
the implementation supports leap seconds, and if local time is
UTC, and if I have a struct tmx that corresponds to 1997-06-30
00:00:00, and then add 1 to tm_mday and invoke mkxtime, I
should get 1997-06-30 23:59:60 due to the intervening leap
second. This is not what I, the programmer, want or expect!
The first sentence in this paragraph reads ``Values S and D
shall be determined as follows''. But the rules that follow
do not _determine_ S and D; they merely place _constraints_
on S and D. This is because the implementation has some leeway
in choosing X1 and X2.
It's not clear in this paragraph whether we're looking at C
code or mathematics. Are we supposed to be using all the C
rules for promotion, conversion, and overflow, or are the
calculations to be done using mathematical integer arithmetic?
The last sentence in the comment about X1 and X2 is
incoherent; I really can't make out what it means.
For the implementation to determine X1 and X2, it needs to
know what D and S are. But D and S are computed from X1 and
X2! More explanation is needed before I can really figure out
what's intended here.
The definition of D is completely unmotivated, and does not
obey the rules of the Gregorian calendar. Among other things,
it uses / and % in places where it should use QUOT and REM.
(And it can't possibly be right without a `100' in it
somewhere. :-) The definition should be rewritten to be
something like the following. (Sorry, I haven't tested this,
as it's less than 30 minutes before the deadline for
submitting comments in the US as this sentence is being
written.)
D = // day offset since 0000-03-01
// contribution from year
Z*365 // number of non-leap days since 0000-03-01
+ QUOT(Z, 4) // Every 4 years ends in a leap year.
- QUOT(Z, 100) // Every 100 years ends in a nonleap year.
+ QUOT(Z, 400) // Every 400 years ends in a leap year.
// contribution from month; note we start from 03-01
+ ((int []){ ...yday offsets, starting in March ...})
[REM(M - 2, 12)]
// contribution from day of month
+ tm_mday - 1
// contribution from time of day
+ QUOT(SS, 86400)
except of course that the expression QUOT(SS, 86400) mishandles
leap seconds as described above.
Section 7.16.3.5
This new function zonetime is if only marginal use; it seems to
be present mostly as a way of defining how mkxtime works.
The definition of leap seconds is incorrect. Leap seconds are
not a UTC-UT1 offset. The absolute value of the difference
between UTC and UT1 is at most 0.9 seconds, by definition.
The changes to 7.16 seem to be hastily edited: there are a number
of what seem to be typographical errors. The changed text is not
explained, and the typos make it hard to understand what was
intended. Here are some of the typos that I spotted despite these
problems:
Section 7.16.1 paragraph 2. _LOCALTIME ``must be outside the
range [-14400, +14400].'' Presumably this should be [-1440,
+1440], i.e. one day's worth not ten.
Section 7.16.2.6 paragraph 3.
The definition for QUOT yields numerically incorrect results
if (b)-(a) or (b)-(a)-1 overflows. I suggest replacing it
with the following definition, which is clearer and free of
problems with overflow. This definition relies on C9X's new
guarantees about integer division.
#define QUOT(a,b) ((a)/(b) - ((a)%(b) < 0))
Similarly, REM can overflow if (b)*QUOT(a,b) overflows. Here
is a better version.
#define REM(a,b) ((a)%(b) + (b) * ((a)%(b) < 0))
The definition of Z can be written more compactly as:
Z = Y - (M < 2);
Section 7.16.3.6 paragraph 5.
``If this value is outside the normal range, the characters stored
are unspecified.'' What is the ``normal range''? The range as
output by localtime, the range of the Gregorian calendar, or
the limits as specified in 7.16.2.6?
Suggestion
Drop all changes to the <time.h> section for this revision of
the C Standard.
Bring in experts in this area for the next revision of the
C Standard. I suggest working together with the members of the
Time Zone Mailing list <[email protected]>.
Build on existing practice rather than relying on committee
inventions, which have been error-prone in this area.
If these suggestions is not followed, a lot of changes are
needed to this section, as suggested by the above discussion;
please contact me if you need more details.
Response Code: N
------------------------------------------------------------------------
PUBLIC REVIEW COMMENT #11
------------------------------------------------------------------------
Comment 1.
Category: Request for clarification
Committee Draft subsection: 6.5.2.1, 6.1.2.8.2, K.2, K.3.9, K.5.8.
Title: Bitfield widths
Detailed description:
Section 6.5.2.1 #8 states that a bitfield can be declared as type
'int', 'signed int', or 'unsigned int'. It further states that "a
bitfield is interpreted as a signed or unsigned integer type consisting
of the specified number of bits".
However, there is no mention of whether or not the number of bits in a
bitfield is limited to the number of bits in an '[unsigned] int'.
6.5.2.1#8 implies that a bitfield can be declared with the number of
bits in /any/ integer type. This implies that bitfields can be
declared to have any number of bits, up to the number of bits in a
'long' or even a 'long long' integer type.
Presumably, then, the following declaration is conforming and portable:
struct Widdle
{
unsigned int a: 29; // Exceeds bits in UINT_MAX
unsigned int b: 33; // Exceeds bits in ULONG_MAX
};
The width of member 'a' exceeds the minimum ISO width of 'unsigned int'
of 16 bits, so it must take on the type of 'unsigned long int'.
Similarly, the width of member 'b' exceeds the minimum ISO width of
'unsigned long int' of 32 bits, so it must take on the type of
'unsigned long long int'.
This seems like a reasonable interpretation. But is it correct?
Sections K.2, K.3.9, and K.5.8 state that a compiler may allow types
other than 'signed int' and 'unsigned int' for bitfields as an
extension. Assuming that the interpretation above is correct, such
extensions are superfluous; all bitfield types would be equivalent, and
would only be distinguished by their signedness.
Suggestion:
The maximum allowable size for a bitfield should be mentioned in the
standard, perhaps as a footnote to section 6.5.2.1#8:
6.5.2.1
...
[#8]
...
A bitfield is interpreted as a signed or unsigned integer type
consisting of the specified number of bits *.
* This implies that a bitfield may contain any number of bits,
up to the number of bits in the widest integer type (umaxint_t).
If instead it is deemed a limitation that bitfields cannot have a width
that exceeds the number of bits in an '[unsigned] int', then this
should be mentioned, perhaps as a footnote. Further, it should be
noted in appendix K that exceeding this limit is implementation-defined
behavior.
Response Code: M
The maximum allowable size is a constraint (see paragraph 3).
-----------------------------------------------------------------
RESPONSE CODES
-----------------------------------------------------------------
AD The request is reflected in the current draft.
AL Changes have been made along the lines you suggested.
AM This proposal would introduce an undesired ambiguity.
AN The Committee has voted against this idea.
AW The Standard provides another way to do this.
AY The Committee has voted for this idea.
BC This proposal would invalidate too much existing source code.
BD The Standard reflects the base document in this regard.
BE The Standard remedies a deficiency in the base document.
BS This concerns matters beyond the scope of IEC/ISO WG14 / NCITS J11.
CC This was considered a comment rather than an issue.
CE The Committee believes this is clear enough as is.
CS Compiler ``switches'' can produce multiple implementations.
DA The Committee chose a different approach to deal with this issue.
DI In some cases, this proposal would be difficult to implement.
E This was accepted as an editorial change.
EA Extensions are allowed in this regard, but they are not required.
EF This could not be efficiently implemented on many architectures.
EI The facility was based on an existing implementation.
EL Adding too many facilities would unduly enlarge the language.
EN This proposed editorial change was discussed but not accepted.
EP The Standard reflects widespread existing practice in this regard.
ER This was accepted as an editorial change to the Rationale.
ES This was accepted as an editorial change to the Standard.
EY This editorial change has been made.
FE The Standard must accommodate anticipated future evolution.
IF It was decided to allow implementors freedom in this regard.
II This is an issue for the implementor, not the Standard.
IP This would impair development of portable source code.
LU This was considered to be an invention of limited utility.
M This is a misinterpretation of correct wording in the document.
MC Existing implementations may indeed not meet Standard criteria.
N The Committee discussed this proposal but decided against it.
NB This does not appear to be based on prior art.
NC No change to the existing wording was considered necessary.
NI This was not considered an issue requiring action.
NL The Committee decided not to have ``levels'' of the Standard.
NP A specific proposal is needed before action can be taken.
NT The Standard is not intended to double as a tutorial.
NU XXX The Committee didn't understand this proposal as worded. XXX
OP The Standard supports a one-pass compilation model.
PA This proposal conflicts with too much prior art.
PC This proposal would conflict with other portions of the Standard.
PD The Standard reflects the result of previous discussion of this issue.
PO This proposal would preclude code optimization.
PR The Committee has reaffirmed this decision on more than one occasion.
Q This was considered a request for information, not an issue.
QI Quality of implementation is beyond the scope of the Standard.
RR This issue can be resolved by a careful reading of the Rationale.
RS This issue can be resolved by a careful reading of the Standard.
SC This would run counter to the historical ``spirit of C''.
SD The Committee has made significant changes in this area.
UC Such a constraint on implementations was deemed undesirable.
TE This proposal contains insurmountable technical errors.
TR This is too radical a change to adopt at this stage.
UF This proposal would unduly favor a limited class of architectures.
VA The Standard must accommodate a variety of architectures.
VC The Standard must accommodate a variety of character sets.
VE The Standard must accommodate a variety of environments.
VP The Standard must accommodate a variety of preprocessing methods.
WR The present wording is required for accuracy and completeness.
Y This proposal was accepted.
------------------------------------------------------------------------