JTC1/SC22/WG14
N873
Disposition of Comments Report for FCD 9899, Ballot Document N2872
Document number: WG14 N873
This disposition of comments document contains only the responses to
comments of the SC22 ballot document N2872.
_____beginning of Canada Comments _____
Canada:
Comment #1:
This was addressed by changes to the notion of block, and 6.5.2.5,
Compound literals Example 8 has been revised accordingly.
Comment #2:
The Committee believes the description is clear enough, and the
suggested changes would introduce an inconsistency in the style
of constraint wording. There is consistent precedent in the way
that the terms are used: a grammar term used in a constraint section
generally refers to the explicit use of that term within the
associated syntactic construct being described, not other nearby
or nested uses of the term.
Comment #3:
The Committee agrees undefined behavior is appropriate, and does
not require changes to existing implementations or strictly conforming
programs. But we believe no diagnostic is necessary.
Comment #4:
Any changes along these lines would reduce consensus within the
Committee. The current state of this issue has been discussed
and reaffirmed on several occasions.
________end of Canada Comments; beginning of Denmark Comments_________
Denmark
Comment #1:
Accepted.
Comment #2:
The request for 31-character significance regardless of character
encoding cannot be accommodated by older software environments that
have 31-byte graphic character limitations in various tools beyond the
C language translator. In order to make such systems improve
significantly beyond the limit in the current wording (31 basic
character set characters), the changes needed would be equivalent to
the changes needed to eliminate the limits altogether. This is clearly
the direction for the language and should be emphasized in Future
Language Directions. The increase from the 6-character mono-case
C90 language to the 31-character case-significant limit acknowledges
the actual state of common-denominator tool technology rather than
requiring massive change. The current wording supports a simple
clear transitional scheme to get full functionality for all character
codes at the expense of fewer characters than the expected future
requirement. Final resolution was to add a Future Direction to go to
255-byte minimum.
Comment #3:
The Committee acknowledges that the standard is not perfect in this
area, but the effort required to define exact mappings from the large
number of concepts in the standard to new SC22 terminology, and
then fully scrub the text to use the new terminology accurately would
introduce significant risk to the production of a useful and correct
document in the working timeframe for this revision.
Editorial changes that achieved consensus in full Committee:
1. In 3.5 definition of "character", add a forward reference to
new sub-clause 3.20, definition of "wide character".
2. Add 3.20, definition of "wide character" as follows:
wide character bit representation that fits in an object of
type wchar_t, capable of representing any character
supported by the implementation.
NOTE: This use of the word "character" refers to the abstract
notion, such as defined in 3.6.3 of ISO/IEC TR 10176:1998
Information Technology Guidelines for the Preparation of
Programming Language Standards. It does not refer to the
technical term defined in 3.5 above.
3. Remove italics from "wide character" in 6.4.4.4 Character
constants.
4. Add ISO/IEC TR 10176:1998 to the Bibliography
5. Delete 7.1.1p4 and its footnote 140.
________end of Denmark Comments; beginning of France Comments_________
France
Comment C:
See response to Canada comment 4.
Comment #1:
Addressed by removal of the struct tmx-based functions.
Comment #2:
Agreed, the struct tmx material was removed.
________end of France Comments; beginning of Japan Comments_________
Japan
Comment #1:
Rationale will be added.
Comment #2:
Accept the suggestion as editorial.
Comment #3:
Changes along the lines suggested will be made. Footnote 15 formerly
referenced by paragraph 3 will be deleted.
Comment #4:
Other changes to the document make the suggested change unnecessary.
The text "Each universal character name that cannot be one of the
above" has been removed from the list of preprocessing tokens in
6.4 Lexical Elements, as it is covered by having "identifier"
in the list. Syntactically, any UCN can be part of an identifier
(however semantically, some UCNs are disallowed). Since UCNs are
removed from the syntax there is no longer any need to add
them to the list that contains the categories list in paragraph 8.
Comment #5:
As an editorial change, Subclauses 7.20.7 and 7.20.8 will be
rewritten to use "wide character" in place of "code." As part
of this change, "terminating zero code" will be changed to "null
wide character."
Comment #6:
The requested Rationale will be added.
Add a new paragraph to the end of the Rationale Subclause 5.2.4:
In C90, the goal of supporting machines with only 64K of memory
as both hosts and targets helped determine the environmental and
translation limits. In C9X, the minimum amount of memory for the
target machine was raised to 512K. In addition, the Committee
recognized that small machines rarely serve as a host for a C
compiler: programs for embedded systems or small machines are
almost always developed using a cross compiler running on a
personal computer or workstation. This allows for a great
increase in some of the translation limits.
Add the following to Rationale Subclause 17.19.6.1:
The C90 limit of 509 maximum characters produced from a single
conversion specifier was increased to 4095 in C9X (approximately
an eight-fold increase) to reflect the increase in the minimum
amount of memory available in the C9X minimum target machine
(See Subclause 5.2.4).
Comment #7:
The notation for floor (similar to the notation for ceil) is
used in ISO/IEC 10967-1 and noted as being a "conventional
notation". The REM notation is used in IEC 60559 where
that standard defines the remainder function.
Comment #8:
The suggested wording was accepted as editorial.
Comment #9:
Accepted as editorial.
Comment #10:
The suggested wording was accepted as editorial.
____ end of Japan Comments; beginning of Norway Comments ___________
Norway:
Comment #1:
To allow examples such as those that appear in this comment would
require interactions between phases 2 (line-splicing), 4 (macro
expansion), and 5 (escape character processing). This would be a
very significant change in specification. Furthermore, the intention
for UCN's and extended source characters was always that an
implementation should be free to map them to a unified internal
form in translation phase 1, instead of waiting until translation 5.
The restrictions on producing UCN-like sequences in intermediate
phases are intended to rule out programs whose behavior
depends on the phase in which UCN's are actually processed in
the implementation. No change will be made.
Comment #2:
The Committee decided to reject this proposal for the following
reasons:
- The current definition matches existing practice in C++
and in a great many C implementations
- The popularity of the extension in C compilers shows that
almost no one is affected by the quiet change. There is
little reason to even recommend a diagnostic be issued.
- Many programmers draw a "box" around their comments
using "*"
Comment #3:
The Committee is not considering requests for new features
at this point.
Comment #4:
The Committee is not considering requests for new features
at this point.
Comment #5:
Same as Denmark #3.
Comment #6:
An implementation is free to convert characters not in the
execution character set to different characters or to always
convert to the same character.
The character that results from converting a character not in the
execution character set must not cause a compile-time error.
However, an implementation is free to issue a diagnostic as
long as the implementation successfully translates the program.
The Committee believes that changing this behavior at this point
would decrease consensus. However, a proposal that allows (but
does not require) implementations to fail would have some support
in a future standard.
Comment #7:
Same as US Comment #17 (Paul Eggert) Comment #1.
An implementation is allowed to insert "\" in some instances but
not others. Changing this behavior would decrease consensus.
However, in light of your concerns the following change was made:
Change to Subclause 6.10.3.2 (The # operator) paragraph 2:
Replace "unspecified" with "implementation-defined"
This change requires implementations to document their behavior
when stringizing a UCN.
Comment #8:
Withdrawn.
Comment #9:
The Committee believes that moving the examples to another
section would not improve the document.
The request for more (or modifications to the existing) examples
to show uses of national characters and UCNs has been referred
to an editorial committee for possible action.
Comment #10:
Accepted in principle; new words:
Replace 6.4.3p2 by:
A universal character name shall not specify a character short
identifier less than 000000A0, other than 00000024 ($),
00000040 (@), or 00000060 (`), nor one in the range 0000D800
through 0000DFFF inclusive.[*]
[*] These characters are the C0 and C1 control character ranges
of ISO 8859, the basic character set, and the "surrogates"
used in Unicode as an alternative encoding mechanism.
Comment #11:
The following change to the document eliminates the confusion.
Delete "or 'AB'" from 6.4.4.4 paragraph 2.
In 6.4.4.4 paragraph 10, modify the appropriate
sentence to read:
"The value of an integer character constant containing more
than one character, such as 'ab', or containing a character or
escape sequence not represented in the basic execution
character set, is implementation-defined."
Comment #12:
The Committee believes that the suggested change does not
improve the document. The primary virtue of the example
is its historical significance as a common, if poor, implementation.
Comment #13:
This is an ISO-10646 term, as noted at the primary reference
in 6.4.3 (#4). It will be added to the index to resolve the
natural question that arises when seeing it for the first
time in 5.4.2.1.
Comment #14:
An editorial change along these lines will be made.
Comment #15:
No. The intent is that they encode a single date and time that
represents the time of translation. This is specified by
the terminology of 6.10.8, which describes "the" date/time
of translation of the source file, implying there is exactly
one such date/time. The terminology here will be corrected.
Comment #16:
No, clear enough, this reason is mentioned in the footnote.
Comment #17:
Yes, the intent was that "deleting every instance of restrict from
every preprocessing translation unit that constitutes the entire
program does not change its meaning", and an editorial change
along these lines will be made.
Comment #18:
This proposal has appeared in different forms at various times.
Such proposals have generally run into problems with the details
of specification, since the way that C specifies its type system
is not the same as C++. A carefully-worded correct proposal
with exact text differences has not been put forward. At this
point in the standardization process, development and evaluation
of such a proposal would be too large an undertaking.
Comment #19:
Yes, the term "indeterminate value" will be added to Terms
and Definitions:
indeterminate value -- A value that may be either a valid
value of the type or a trap representation.
Comment #20:
While this use of implementation-defined behavior does not
exactly conform to the letter of the definition in terms of
providing explicit alternatives, the only reason is that
there are too many alternatives to enumerate. The intent
is that any reasonable hardware implementation of this
operation would be allowed, as long as it does not produce
trap values.
The intent is that the implementation must document the
behavior. As the behavior is highly system-dependent,
an enumeration of allowed behaviors did not seem useful.
Yes, there is no requirement on the file position indicator
except that it not be a trap representation.
Wording change:
[#5] An integer may be converted to any pointer type. |
Except as previously specified, the result is
implementation-defined, might not be properly aligned, and
might not point to an entity of the referenced type.49)
[#5] An integer may be converted to any pointer type. |
Except as previously specified, the result is
implementation-defined, might not be properly aligned,
might not point to an entity of the referenced type49), or
it might be a trap representation.
Comment #21:
No change to the existing wording was considered necessary.
The definition of the term alignment uses the term address
in the sense of hardware addresses, and is used to explain
the practical reason for certain aspects of the language.
Types provide a mapping of values into a representation
in a particular C implementation. The concept of alignment
expresses certain practical constraints not only on how
types are represented but also on where they may be placed
in memory to allow reasonably efficient access. It does not
imply that the "address" values in C are identical to hardware
addresses, only that alignment characteristics of hardware
addresses will generally affect what liberties can be taken
with C addresses.
The address-of operator returns a pointer, but not all
pointer values are obtained through this operator. Furthermore,
not all pointer values are appropriate for accessing objects.
The text "the address of each individual byte" refers to a C
address. The point is that each byte of an object
can be addressed through pointers, which does not imply
that every hardware address can be expressed in a pointer,
or that every pointer value refers to a hardware address.
Comment #22:
No change to the existing wording was considered necessary.
Comment #23:
The word "character" in the specifications does not imply the
type char, rather it refers to the result of converting the integer
value of the argument to an unsigned char type. So there is
no behavior problem or need for the user to perform conversion
by hand.
Comment #24:
This is acknowledged as a potential problem, and that systems
with one's complement /and/ sizeof(int) == 1 would suffer from
such a limitation. However, this limitation on the values used
with these library functions was considered more acceptable
in practice than classifying any implementation with
INT_MAX - INT_MIN < UCHAR_MAX as non-conforming.
____ end of Norway Comments; beginning of United Kingdom comments ____
United Kingdom
Comment NC: The fpclassify macro
Yes, the suggested words will be added.
Comment NC: Conventions
No, the intention is to not require errno to be set for errors.
The intention is that errno may be set for errors. 7.5 Errors
<errno.h> already allows errno to be set, even if there are no
errors, for library function calls.
Comment Item A:
See #0126, from United Kingdom.
Comment Item B:
This was accepted as an editorial change to the Rationale.
Words similar to the following will be added to the rationale:
The Committee's model is that the floating-point environment
(status flags and control modes) is part of the global state,
just like errno. Therefore, the floating-point environment
has values as of the time longjmp was called.
Comment Item C:
This was accepted as an editorial change to the Rationale.
Words similar to the following will be added to the rationale:
The Committee's model is that the regions of code that are under
FENV_ACCESS OFF do not have to maintain the exception flags,
even if there are regions with FENV_ACCESS ON elsewhere in
the program.
Comment #0079:
The Committee feels that it is clear enough that implementations
need not interpret trailing white space on a line as significant,
especially in fixed-width text environments.
In 5.2.1p3 it says, "In source files, there shall be some way of
indicating the end of each line of text; this International
Standard treats such an end-of-line indicator as if it were a
single new-line character." This statement clearly gives an
implementation latitude in interpreting end of line indications;
its very vagueness was carefully worded to avoid constraining
implementations in fixed-width text environments.
In 6.10.3p7 it says, "Any white-space characters preceding or
following the replacement list of preprocessing tokens are not
considered part of the replacement list for either form of
macro." In 6.10.3.2p2: "White space before the first
preprocessing token and after the last preprocessing token
composing the argument is deleted." And in 7.19.2p2:
"Whether space characters that are written out immediately
before a new-line character appear when read in is
implementation-defined." These statements clearly
establish various contexts in which trailing white
space is not significant.
Comment #0082:
For the requirement that all required members of the source
character set have positive (and therefore non-zero) values,
see 6.2.5p3: "If a member of the required source character
set enumerated in 5.2.1 is stored in a char object, its
value is guaranteed to be positive."
Comment #0083:
In response to this comment, the Committee has taken the step
of specifying the translation phase 1 mapping from the source
file multibyte character set to the source character set as
being implementation-defined, and thus requiring implementations
to document the mapping. It is expected that, if an implementation
accepts source in some multibyte character set, that this same
character set will be used as the execution character set in some
locale. Implementations are already required to document locale-
specific behavior, and so implementations which support multibyte
execution character sets are already required to document (or more
likely, refer to some existing specification for) supported multibyte
character sets. When implementations are also required to describe
source multibyte character sets, it will clearly involve less
documentation effort if they can use the same specification for
source and execution character sets. (This specific change was
also motivated by the fact that the C++ standard already specifies
the translation phase 1 mapping as being implementation-defined).
Comment #0085:
We will correct rationale document by removing the phrase
"such as EBCDIC".
Comment #0086:
The Committee reaffirmed the CD ballot resolution.
Comment #0092:
The behavior described is already allowable but not required.
Attempting to require this behavior provided "the implementation
can determine that ...", does not add any actual verifiable requirement.
Comment #0096:
Yes, accept the change with an additional footnote in 7.14.1.1.
Comment #0102:
The Committee has substantially accepted this proposal. A Future
Direction will be added, along the lines of, "Declaring an identifier
with internal linkage at file scope without the storage-class specifier
static is an obsolescent feature." The limitation to file-scope is
necessary because using the extern keyword is the only way to write a
declaration of an internal-linkage identifier at block scope.
The proposal, "Declaring (when not defining) an identifier with
internal or external linkage with no storage-class specifier is
also deprecated," did not seem to make sense. Every valid
file-scope object declaration with no storage-class specifier
is a definition (at least tentative) with external linkage.
Therefore it is already impossible to declare without defining
an identifier with internal or external linkage and no
storage-class specifier.
It is widely expected that implementations may/should be able to
warn about obsolescent/deprecated features, so no specific statement
about diagnostics for these cases was considered necessary.
Comment #0106:
While the Committee acknowledges that this area is complex,
it was not felt that adding a new kind of linkage would offer
real simplification. The questions and issues raised can be
addressed from the current wording. However, we do think that
a forward reference from 6.7.4 Function specifiers to 6.9 External
definitions is justified.
Specific questions and answers:
> ...joe has to have external linkage...but is not an external
> definition by this section.
Correct.
> Precisely what is the linkage of an inline definition?
Definitions do not have linkages, the rules for linkage are
unchanged.
> Some people believe it has no linkage, but I can't find...
It's not that it has "no" linkage (which is a particular kind
of linkage), but rather that an inline definition in itself
does not does not determine what the linkage is. As the
author previously surmised "joe has to have external linkage".
> paragraphs 7 and 8 are misleading... in particular. "A file
> scope declaration with extern creates an external definition"...
These paragraphs are in examples, which are not normative. The
words quoted above were part of a specific example, to which
they were applicable and correct. The comment quotes the words
out of context and applies them to a different example, to which
they are not applicable.
> Unless this section can be integrated...
The suggested forward reference should clarify that the rules
here for inline definitions modify the more general definition
of external definition given in 6.9.
Comment #0112:
Rationale for rejecting new feature ALIGN_MAX.
There was a great deal of discussion about this. Along the way it
was proposed that a superior solution might be to define a new
type whose size and alignment had the maximal values for the
implementation. This would allow use of the type in a union
to cause it to be maximally aligned, and sizeof could be applied
to it to obtain the requested value.
However, various implementation issues with the type proposal
were brought up, and it was not adopted. It was decided not to
drop back to the proposed constant value because it wasn't
a full solution to the problem - it was felt that future
standards work might provide a full solution, which would
supercede the requested feature.
Comment #0114:
The current index for state-dependent encoding lists 5.2.1.2
Multibyte characters.
These paragraphs explain concepts that apply to the whole document
including the entire library. And we believe that the meaning
is clear enough in all sections of the library specification.
Comment #0120:
No change to the existing wording was considered necessary.
The rounding in C only has to apply to addition. Therefore, it is
insufficient utility to force implementations to document it.
Comment #0126:
This proposal was accepted. We will drop the clause "or unless
the function is known not to use floating point" from both
paragraphs.
Comment #0129:
No change to the existing wording was considered necessary.
The suggested change conflicts with prior art.
Comment #0130:
This proposal was accepted. The suggested wording will be added.
Comment #0133:
No change to the existing wording was considered necessary.
The model the Committee has chosen is that the rounding mode can
always be changed to the rounding direction macros that are defined.
Also, there is sufficient utility as is.
Comment #0134:
No change to the existing wording was considered necessary.
The suggested change conflicts with prior art.
Comment #0135:
Rationale for rejecting new features in feholdexcept.
The new feature was motivated by the observation that the function
was unimplementable on some hardware, based on an inference
that the function required the ability to continue from an
invalid exception. However, the function as specified provides
a return status that indicates whether or not non-stop exception
handling was successfully installed. Systems described in
this comment would implement the function by returning a non-zero
value. A finer-grained approach such as the one suggested was
considered to require substantial new complexity in both the
specification and on implementations than was warranted by the
recommendations of the NCEG.
Comment #0137:
No change to the existing wording was considered necessary.
From what we understand, machines that support multiple floating-point
arithmetics use the same type of arithmetic for all three types; that
is, float being IEEE, double being Cray, and long double being IBM is
not allowed.
If float and double are IEEE and long double is non-IEEE with respect
to infinity, then they are in violation of 6.3.1.5 Real floating types
(which requires that the value is unchanged when promoted to long
double).
The Committee believes that the few, if any, arithmetics where float
does not have infinity, but double or long double do, would only use
the common intersection of the types.
There is insufficient utility to justify complicating the interface.
Comment #0138:
No change to the existing wording was considered necessary.
The Committee attempted to add support for signalling NaNs, but found
that too many areas were impacted (more than what you are requesting
to be changed) for little utility.
Comment #0142:
This was accepted as an editorial change to the Rationale.
Words similar to the following will be added to the rationale:
It means more than ordinary roundoff. For example, for IEEE-754 in
round to nearest, the normal error is at most 0.5 unit in the last
place (ULP). But for finite numbers larger than the largest finite
number, the error is more than 0.5 ulp to either of the two possible
machine representations. For subnormal numbers, since the precision
is reduced, the error is larger than 0.5 ulp. And for numbers smaller
than the smallest finite number, the error is more than 0.5 ulp to
either of the two possible machine representations.
Another Committee viewpoint is: Since an implementation is allowed to
document that its floating-point accuracy is unknown, it is too big of
a burden to require documenting extraordinary roundoff error.
Comment #0143:
Changes have been made along the lines you suggested. This issue
is answered in the response to US-4 comment Rudd #8. The math
library was made atomic (like in C90) and the LIA-1
conformance was altered.
Comment #0144:
No change to the existing wording was considered necessary.
IEEE-754 appendix says that the sign bit may not be used to
distinguish quiet NaNs from signalling NaNs. Also, copysign
and -x do honor the sign of NaNs.
While the suggested change is rejected, a footnote along the lines of
"Arithmetics that have unsigned zeros will be treated as positive
zeros." will be added.
Comment #0147:
This was accepted as an editorial change to the Rationale.
Words similar to the following will be added to the rationale:
copysign and signbit need not be consistent with each other if the
arithmetic is not consistent in its treatment of zeros (copysign will
treat -0.0 as positive, while signbit will treat it as negative). For
example, while IBM S/370 has instructions to flip the sign bit (hence,
it is possible to create a minus zero), +/-0.0 * +/-1.0 is always +0.0
(hence, negative zeros are not treated consistently there).
Comment #0153:
See response to US-2 Comment 1 (John Hauser).
Comment #0154:
No change to the existing wording was considered necessary.
This generic function is needed to support the model of complex
adopted by the Committee.
Comment #0156:
This proposal was accepted. The suggested change will be
added to J.5 Common extensions (rather than to the requested
7.6 <fenv.h>).
Comment #0158:
This was accepted as an editorial change to the Rationale.
Words similar to the following will be added to the rationale:
errno and the floating-point exception status flags are independent
error reporting mechanisms.
Comment #0161:
No change to the existing wording was considered necessary.
This issue is answered in the response to US-4 comment Rudd #4.
Comment #0162:
No change to the existing wording was considered necessary.
The Committee has chosen a model where one part being INF and the
other part is a NaN is considered an INF (not a NaN). The Committee
intentionally has not defined a complex NaN.
Note: This issue is similar to US-16 comment Rudd #9.
Comment #0163:
Create a new section G.3 (immediately after G.2) named
"Conventions". Move the first three sentences of G.4.1 [#4]
into the new section G.3.
Comment #0164:
Changes have been made along the lines you suggested.
Paragraph 5 is as strong as intended.
Part of the reason the complex annex is informative is the Committee
is waiting for feedback from implementators before we consider making
it normative.
Comment #0165:
No change to the existing wording was considered necessary.
Trap-and-resume is permitted by C9X for floating-point exceptions.
Exceptions can be turned into raise of SIGFPE by the implementation.
The signal handler for SIGFPE can compute the corrected value and then
may (if the implementation supports the feature) do a longjmp() to
resume execution. This is a valid LIA-1 model notification; see E.9
PL/I page 78 (where it is called notification through alteration of
control flow). There is no LIA-1 requirement that the exceptional
operation that caused the notification be resumed with a corrected
value; just that the program be resumed.
Also see US comment Rudd 8.
Comment #0201:
Withdrawn.
Comment #0244:
Accepted in principle; new wording:
In 6.7.5.2p3, change:
If the size expression is not a constant expression, and it is
evaluated at program execution time, it shall evaluate to a value
greater than zero.
to:
If the size expression is not a constant expression:
if it occurs in a declaration at function prototype scope,
it shall be treated as if it were replaced by *; otherwise
each time it is evaluated it shall {evaluate to, have} a
value greater than zero.
and make the change to 6.7p7 given at the end of the proposal.
Comment #0246:
Accepted in principle; new wording:
Change 6.7.2.2p4 first sentence to read:
Each enumerated type shall be compatible with /char/ or a signed
or unsigned integer type.
Comment #0248:
The current draft addresses this issue.
Comment #0272:
The current draft addresses this issue.
Comment #0273:
Accepted in principle; new wording:
In 6.7.5.3p3, change:
If the size is not present ... scope (113).
to:
If the size expression is empty ... scope (113); such arrays are
nonetheless complete types.
Comment #0277:
Accepted. The exact changes are to delete the first sentence of
6.5.2.3p5:
With one exception, if the value of a member of a union object is
used when the most recent store to the object was to a different
member, the behavior is implementation-defined..
and also footnote 70.
Comment #0278 - accepted. The exact changes are:
In 7.19.8.1p2, add after the first sentence:
For each object, /size/ calls are made to the /fgetc/ function
and the results stored, in the order read, in an array of
/unsigned char/ exactly overlaying the object.
In 7.19.8.2p2, add after the first sentence:
For each object, /size/ calls are made to the /fputc/ function,
taking the values (in order) from an array of /unsigned char/
exactly overlaying the object.
Comment #0287:
Accepted in principle. The normative changes are to be made as
given. The optimisation issue has been drawn to the attention of the
Rationale editor.
Comment #0209:
Rejected; this is a new issue not raised at a previous stage.
Comment #0214:
This is viewed as an editorial change which has been accepted.
Comment #0222:
Accepted in principle; new words:
Add to the end of 6.7.2.1p3:
A bit-field shall have a type that is a qualified or unqualified
version of /_Bool/, /signed int/ or /unsigned int/, or of some
other implementation-defined type.
Delete the first sentence of 6.7.2.1p8.
Comment #0232:
Rejected; the issues are more complicated than would be
addressed by this proposal. In particular, there is no
requirement that different locales use the same encoding of
wchar_t.
Comment #0245:
Accepted. The exact changes are:
Delete the last sentence of 6.2.5p23. Change 6.7.2.1p15 to read:
[#15] As a special case, the last element of a structure
with more than one named member may have an incomplete array
|| type. This is called a flexible array member. With two
|| exceptions the flexible array member is ignored. Firstly, the
|| size of the structure shall be equal to the offset of the last
element of an otherwise identical structure that replaces
the flexible array member with an array of unspecified
length.95) Secondly, when the . or -> operator has a left
|| operand which is, or is a pointer to, a structure with a flexible
|| array member and the right operand names that member, it
behaves as if that member were replaced with the longest
array, with the same element type, that would not make the
structure larger than the object being accessed; the offset
of the array shall remain that of the flexible array member,
even if this would differ from that of the replacement
array. If this array would have no elements, then it
behaves as if it had one element, but the behavior is
undefined if any attempt is made to access that element or
to generate a pointer one past it.
Finally, add further example text after 6.7.2.1p18:
The assignment:
*s1 = *s2;
only copies the member n, and not any of the array elements.
Similarly:
struct s t1 = { 0 }; // valid
struct s t2 = { 2 }; // valid
struct ss tt = { 1, { 4.2 }}; // valid
struct s t3 = { 1, { 4.2 }}; // error; there is nothing
// for the 4.2 to initialize
t1.n = 4; // valid
t1.d [0] = 4.2; // undefined behavior
Comment #0254:
Partially accepted in principle; new words:
Add a new subclause 7.8.3:
7.8.3 Miscellaneous functions
7.8.3.1 The imaxabs function
Synopsis
#include <inttypes.h>
intmax_t imaxabs(intmax_t j);
Description
The imaxabs function computes the absolute value of an integer j.
If the result cannot be represented, the behavior is undefined.
Returns
The imaxabs function returns the absolute value.
7.8.3.2 The imaxdiv function
Synopsis
#include <inttypes.h>
imaxdiv_t imaxdiv(intmax_t numer, intmax_t denom);
Description
The imaxdiv function computes numer/denom and numer%denom in a
single operation.
Returns
The imaxdiv function returns a structure of type imaxdiv_t,
comprising both the quotient and the remainder. The structure shall
contain (in either order) the members quot (the quotient) and rem
(the remainder), each of which have the type intmax_t. If either
part of the result cannot be represented, the behavior is undefined.
7.8p2 will need consequential changes.
Comment #0274:
Accepted in principle; new words:
Add a footnote to 6.3.1.3p2:
The rules describe arithmetic on the mathematical value, not
on the value of a given type of expression.
Comment #0275:
Accepted. The exact change is to insert
whose results are integer constants
at the end of the first sentence of 6.6p8.
Comment #0279:
Accepted option B. The exact changes are:
Change the last part of 6.2.6.2p2 from:
If the sign bit is one, then the value shall be modified in one
of the following ways:
-- the corresponding value with sign bit 0 is negated;
-- the sign bit has the value -2N;
-- the sign bit has the value 1-2N.
to:
If the sign bit is one, then the value shall be modified in one
of the following ways:
-- the corresponding value with sign bit 0 is negated (/sign and
magnitude/);
-- the sign bit has the value -2N (/two's complement/);
-- the sign bit has the value 1-2N (/one's complement/).
The implementation shall document which shall apply, and
whether the value with sign bit 1 and all value bits 0 (for the
first two), or with sign bit and all value bits 1 (for one's
complement) is a trap representation or a normal value. In
the case of sign and magnitude and one's complement, if
this representation is a normal value it is called a /negative
zero/.
and insert two new paragraphs immediately afterwards:
If the implementation supports negative zeros, then they
shall only be generated by:
- the & | ^ ~ << and >> operators with appropriate arguments;
- the + - * / and % operators where one argument is a negative zero
and the result is zero;
- compound assignment operators based on the above cases.
It is unspecified if these cases actually generate negative zero or
normal zero, and whether a negative zero becomes a normal zero or
remains a negative zero when stored in an object.
If the implementation does not support negative zeros, the behavior
of an & | ^ ~ << or >> operator with appropriate arguments is
undefined.
Comment #0281:
Accepted in principle; new words:
Change 6.10 syntax as follows:
group-part:
if-section
control-line
text-line
# non-directive
Add to the syntax in 6.10:
text-line:
pp-tokens/opt new-line
non-directive
pp-tokens new-line
Add a paragraph to 6.10 description:
A text-line shall not begin with a # preprocessing token. A
non-directive shall not begin with any of the directive names
appearing in the syntax.
When in a group that is skipped (6.10.1), the syntax of all
preprocessing directives shall allow any sequence of
preprocessing tokens between the directive name and the
following newline.
Comment #0282:
Accepted. The exact changes are to add to the list in 6.10.8p1:
__STDC_HOSTED__ The decimal constant 0 if the implementation
is a freestanding one and the decimal constant 1 if it is a
hosted one.
Comment #0283:
Accepted. The exact changes are:
In 7.14.1.1p5, change:
or the signal handler calls any function in the standard library
other than the /abort/ function or the /signal/ function
to:
or the signal handler calls any function in the standard library
other than the /abort/ function, the /_Exit/ function, or the
/signal/ function
Add a new subclause within 7.20.4:
7.20.4.X The _Exit function
Synopsis
#include <stdlib.h>
void _Exit (int status);
Description
The /_Exit/ function causes normal program termination to occur,
and control to be returned to the host environment. No functions
registered by the /atexit/ function or signal handlers registered
by the /signal/ function are called. The /_Exit/ function never
returns to the caller. The status returned to the implementation
is determined in the same manner as for the /exit/ function. It
is implementation-defined whether open output streams are
flushed, open streams closed, or temporary files removed.
Comment #0284:
Accepted, using the second alternative wording. The exact change
is to insert a new Constraint in 6.10.3:
In the definition of an object-like macro there shall be white
space between the identifier and the replacement list.
Comment #0285:
Accepted. The exact change is to alter 7.19.5.1p2 to read:
A successful call to the fclose function causes the stream pointed
to by stream to be flushed and the associated file to be closed.
Any unwritten buffered data for the stream are delivered to the
host environment to be written to the file; any unread buffered
data are discarded. Whether or not the call succeeds, the stream
is disassociated from the file and any buffer set by the setbuf
or setvbuf function is disassociated from the stream, and if the
later was automatically allocated, it is deallocated.
Comment #0261:
Accepted in principle; new words:
Append to footnote 138:
The intention is that this will remain a constant of type long
that is increased at each revision of this International Standard.
Comment #0262:
This was discussed, but the majority of national bodies were
against making such a change at this time. Reasons expressed
included the temporary utility of such a feature.
Comment #0269:
This was discussed, but the the Committee was unable to
find a form of words that would address the (theoretical)
problem without undue side-effect elsewhere.
Comment #0270:
Accepted in principle; new words:
Append to 7.20.4.3p3:
If, during the call to any such function, a call to the longjmp
function is made that would terminate the call to the registered
function, the behaviour is undefined.
Comment #0227:
Accepted. The exact changes are in 6.7.7p6:
- change "at least the range [-15, +15]"
to "either the range [-15, +15] or the range [-16, 15]"
- change "values in the range [0, 31] or values in at least the range
[-15, +15]"
to "values in one of the ranges [0, 31], [-15, +15], or [-16, +15]"
Comment #0249:
The current draft addresses this issue.
Comment #0251:
The current draft addresses this issue.
Comment #0252:
Accepted in principle; new words:
In 6.9p3 and p5, change:
... operand of a sizeof operator)
to:
... operand of a sizeof operator whose result is an integer
constant)
Comment #0256:
The wording involved is not part of the current draft.
Comment #0257:
The Committee was not willing to add such a new feature
at this time.
Comment #0276:
This is viewed as an editorial change, but which does not need
to be made.
Comment #0263:
The Committee was unwilling to add such a feature without
input from WG20 (POSIX), which would not have been available
in this timescale.
Comment #0264:
This proposal duplicates UK Comment #0254.
Comment #0265:
The Committee felt that the limited benefit from making this
change was outweighed by the confusion that would be caused,
and noted that previous meetings had decided that this
arrangement was suitable.
Comment #0204:
Accepted in principle; new words:
Replace 5.2.1p1, second sentence, by:
Each set is further divided into a /basic character set/, whose
contents are given by this subclause, and a set of zero or
more locale-specific members (which are not members of t
he basic character set). The combined set is also called the
/extended character set/.
In 5.2.1p3, delete "at least" in the first sentence, and in the
fourth sentence change "In the execution character set" to
"In the basic execution character set".
Replace 5.2.1.2p1, first bullet, by:
- The basic character set shall be present and shall be encoded
using single-byte characters.
In 6.2.5p3, replace "required source character set enumerated in
5.1.2" with "basic execution character set". (Note that the
execution set is more sensible in this context than the source set.)
In 6.4.2.1p3, change "that are not part of the required source
character set" to "that are not part of the basic source character
set".
In 6.4.3p2 and p3, change "required" to "basic".
In 6.4.4.4p8 change "required" to "basic".
Change 7.1.1p2 to:
A /letter/ is one of the 52 lowercase and uppercase letters in the
basic execution character set. All letters are printing characters.
In fprintf p17 change "the multibyte members of the extended character
set" to "the members of the extended character set that consist of
more than one byte", and make the same change in fscanf p24.
Relevant changes in the Annexes will also be required.
Comment #0208:
Withdrawn.
Comment #0097:
Decided against, words will added to the rationale.
Comment #0098:
Decided against, words will added to the rationale.
____ end of United Kingdom Comments; beginning of USA Comments ____
United States of America
US-1 (Douglas Walls)
Comment#1:
The atexit function is free to return non-zero to indicate failure if
called after exit, but atexit is not permitted to crash the program.
Any functions successfully registered by atexit after exit is called
are called in reverse order of registration after the function that
registered them returns.
US-2 (John Hauser)
Comment #1:
The special cases for the atan2 function match those desired for
carg to support the general approach to complex special cases,
which entails avoiding NaNs, even in indeterminate cases where a
non NaN value is deemed more useful. See the response to US-16,
Comment 9.
Comment #2:
The second bullet of F.9.5.4 will be replaced by
-- tgamma(+/-0) returns +/-inf and raises the divide-by-zero exception.
-- tgamma(x) returns a NaN and raises the invalid exception is x is a
negative integer.
The cases
pow(x,+infinity) x < -1
pow(x,-infinity) -1 < x < 0
are defined to be +infinity, instead of NaN or -infinity, because
large -magnitude finite floating-point numbers are all even
integers, hence pow(x,n) is +infinity if x < -1 and n is any
floating-point value of sufficiently large magnitude, and
similarly for the second case.
Regarding pow(-0,y) y < 0 and y not an integer
for points near and to the left of (-0,y), pow returns NaN, and for
points near and to the right, pow returns large positive values,
with pow(+0,y) returning +infinity. Particularly as the sign
of zero can be a computational accident, +infinity was thought
to be the most useful result.
The case pow(-infinity,y) y > 0 and y not an integer
is defined to be consistent with the previous case.
The case of tgamma of x, x a negative integer, deserves a NaN result,
as the mathematical function approaches +infinity on one side of the
argument and -infinity on the other (and hunkers on the x axis between
poles).
Comment #3:
The current fdim spec is believed to be a better match for existing
practice, in both C and Fortran. Support for Fortran codes was a
primary reason for including fdim in the International Standard.
Comment #4:
The Committee believes a significant body of applications will be
better served by the current specification, though acknowledging
that the suggested one would be better for others. The IEEE
treatment of NaNs is not compelling, as these functions, like the
bit manipulation functions mentioned in the comment, need not
be regarded as arithmetic.
US-3 (David Tribble)
Comment #1:
This has been discussed many times within the Committee, and
the current status represents the solution that prompted the greatest
consensus. There are many varying opinions on this issue. In fact,
the opposite change was proposed in another public comment.
Considering this, and in order to maintain consensus within the
Committee, no change will be made.
US-4 (Eric Rudd)
Comment #1:
In the draft standard, the first sentence of 7.12.4.4 [#2] will be
changed to:
The atan2 functions compute the value of the arc tangent of y/x,
in the range [-pi, +pi] radians, using the signs of both arguments
to determine the quadrant of the return value.
Comment #2:
A domain error is not required for these cases. As 7.12.4.4 allows
but does not require a domain error, whether one occurs may vary
among implementations. For IEC 60559 implementations, atan2(0,0)
and atan2(inf,inf) each has a defined numerical result (F.9.1.4),
hence no domain error. Other implementations are allowed to adopt a
definition for atan2 that excludes the inputs (0,0) and (inf,inf) and
regard these cases as domain errors.
Comment #3:
A statement in the draft standard that the range is a closed interval
does not imply that each value in the interval (including endpoints)
is achieved by the function.
Comment #4:
As indicated in the response above to Comment 2, there is some
latitude for definitions of special cases. For certain special cases,
Annex F specifies a numerical result and no floating-point exception
corresponding to a domain or range error. Hence for implementations
supporting the annex, these cases need not be regarded as domain or
range errors. Also see the response to US-16, Comment 9.
Comment #5:
As indicated in the response above to Comment 2, there is some
latitude for definitions of special cases. Whether a domain error
occurs for pow(0,0) depends on the implementation.
Comment #6:
The following statement will be appended to the F.3 bullet that
begins "The fegetround and fesetround functions à": "The
values 0, 1, 2, and 3 of FLT_ROUNDS are the IEC 60559
directed rounding modes."
As in other cases, Annex F adopts IEC 60559 specification by
reference, in order to keep down the size of the draft and to reduce
the chance of documentation errors.
The current specification in 5.2.4.2.2, like in 9899:1990, does not
define the named rounding modes, and in particular leaves
unspecified the treatment of halfway cases in rounding to nearest.
The Committee does not see sufficient benefit from introducing a
requirement that non-IEEE implementations document details of
their rounding modes.
Comment #7:
The term exception was used in two ways. The draft will be
changed to distinguish (a) what will now be called /exceptional
conditions/ as in 6.5 [#5] from (b) floating-point exceptions as
in 7.6.
Comment #8:
The draft standard will be changed to require, like 9899:1990, that
calls to math functions shall not terminate a program.
Comment #9:
The draft standard will be changed to require that each
implementation support either errno, as required in 9899:1990, or
the floating-point exception flags corresponding to domain and
range errors for math functions.
US-5 (Larry Jones)
Comment #1:
Accepted, with some editorial rewording of point 3.
Comment #2:
Accepted in principle; new words:
Add a subclause to clause 3:
Unspecified value
A value of the relevant type where this International Standard
imposes no requirements on which value is chosen in any instance.
Note: an unspecified value cannot be a trap representation.
Add a subclause to clause 3 defining "implementation-defined value"
using wording based on that defining "implementation-defined
behaviour".
Comment #3:
Duplicate of UK#0246.
Comment #4:
Accepted as editorial. The draft has been corrected.
Comment #5:
Accepted as editorial. The draft has been corrected.
US-6 (David Thornley)
Comment #1:
No change will be make, this has been discussed several times
within the Committee.
Comment #2:
This has been discussed many times within the Committee, and the
current status represents the solution that prompted the greatest
consensus. There are many varying opinions on this issue. In fact,
the opposite change was proposed in another public comment.
Considering this and in order to maintain consensus within the
Committee, no change will be made.
Comment #3:
The problem described cannot arise, because a conforming implementation
cannot claim to provide a signed integer type when it does not provide
the corresponding unsigned integer type (See subclause 6.2.5 Types,
and 7.18.1 Integer types).
Comment 4:
Removing long long would reduce consensus within the Committee.
The inclusion of long long has been discussed and reaffirmed on
several occasions, so no change will be made.
Comment #5:
The Committee is not considering requests for new features at this
point.
US-7 (Robert Corbett)
Comment #1:
This was accepted as an editorial change.
Comment #2:
In F.9.4.4, the bullet
-- pow(+/-1,+/-inf) returns ...
will be changed to
-- pow(+/-1,+/-inf) returns +1
The case (-1,+/-inf) is included in the change because
pow(-1,y) is +1 for all sufficiently large magnitude
floating-point numbers y.
Comment #3:
cpow was defined by the usual formula for ease of implementation,
and because the special cases were thought to be somewhat less
important for pow. In order not to preclude a more careful treatment
of special cases, the draft standard will be changed to allow but not
require cpow to be implemented with the formula
cpow(z,c) = cexp(c*clog(z))
A statement will be added that cpow raises exceptions if appropriate
for the calculation of the parts of the result, and may raise spurious
exceptions (as may complex multiply and divide).
Comment #4:
The present semantics of /sizeof/ are those intended by the
Committee. The proposer may wish to read the section
of the Rationale document dealing with VLAs.
Comment #5:
A careful reading of the Standard will show that linkage can
only apply to a specific identifier, and not to two identifiers with
different spellings. The editor has been asked to consider adding a
footnote attached to 6.2.2p1:
Linkage applies to a single identifier. Two different identifiers
(such as /x/ and /y/) can never refer to the same object through
linkage.
Comment #6:
The draft standard will be changed to append to the Semantics
section of 6.4.4.2 the following paragraph:
" Floating-point constants are converted to internal format (as if)
at translation time. The conversion of floating-point constants
shall not raise an exceptional condition nor a floating-point
exception at execution time."
Strengthening requirements for consistent evaluation of decimal
constants was feared too great a burden for some existing
implementations (which may, for example, deliver different
values depending on trailing zeros). Note that the draft standard
requires correctly rounded, therefore consistent, conversion of
decimal constants (except for extreme cases) for IEC 60559
implementation. Strengthening consistency requirements for
hexadecimal constants did not seem worthwhile, as exact
conversion is already required where possible.
US-8 (John Hauser)
Comment #1:
The following statement will be appended to the Description
of frexp: "The results are unspecified if the value of /value/ is
not a floating-point number", with a forward reference to 5.2.4.2.2.
Comment #2:
The suggested fix will be accepted.
Comment #3:
The second and third sentences in 7.12.7.4 [#2] will be changed to
say "A domain error occurs if x is finite and negative and y is
finite and not an integer value.
The fact that pow(+0,+0) is defined in F.9.4.4 may suggest but
does not imply that implementations not supporting Annex F must
adopt this definition. Non IEC 60559 implementations have latitude
in how they define special cases.
Comment #4:
The suggested fix will be accepted.
US-9 (Thomas MacDonald)
Comment #1:
The Committee has voted for this idea.
Comment #2:
The Committee has voted for this idea.
Comment #3:
The following wording change was agreed:
In 6.7.5.2p3, delete the words:
It is unspecified whether side effects are produced when the size
expression is evaluated.
Add a new paragraph between p3 and p4:
Where a size expression is part of an operand to sizeof, and
changing the value of the size expression would not affect
the value of the sizeof expression, it is unspecified whether
or not the size expression is evaluated.
Comment #4:
Addressed by N866, which was adopted.
Comment #5:
Accepted.
Comment #6:
Addressed by N867, which was adopted with the following changes:
On line 90, add the third syntax option:
direct-declarator [static type-qualifier-list/opt assignment-
expression]
On line 98, change:
The optional type qualifiers preceding ...
to:
The optional type qualifiers and the keyword static preceding ...
On line 128, change:
If a size expression follows such a type qualifier ...
to:
If the keyword static appears ...
US-10 (Peter Seebach)
Comment #1:
The Committee has reaffirmed its previous decision not to
include this function.
Comment #2:
The has been addressed by an editorial change, "indeterminately..."
removed from definition.
Comment #3:
Yes, changes along the lines you suggested will be made.
US-11 (Andrew Josey)
Comment #1:
Accepted in principle; new words:
Append to 7.19.8.2p3:
If /size/ or /nmemb/ is zero, /fwrite/ returns zero and
the state of the stream remains unchanged.
US-12 (Larry Jones)
Comment #1:
Making the suggested change would potentially destabilize the document
at this time.
Comment #2:
Accepted as editorial. Jones will provide words.
US-13 (Randy Meyers)
Comment #1:
Accept Future Directions and footnote. Normative text is not needed.
Comment 2:
Accepted.
US-14 (Antoine Leca)
Comment #1:
Duplicated by a French comment.
Comment #2:
Duplicated by a French comment.
US-15 (Douglas Gwyn)
Comment #1:
A careful reading of the Standard will show that a strictly
conforming program cannot exceed any minimum translation
limit.
Comment #2:
A technical report that will address conformance issues will
be debated at some future date.
Comment #3:
The present rules for /main/ were preferable.
Comment #4
The Committee has voted for this idea.
Comment #5:
Withdrawn
Comment #6:
The Committee has voted for this idea.
Comment #7:
This is viewed as an editorial change which has been accepted.
Comment #8:
The Committee has voted for this idea.
Comment #9:
Accepted.
Comment #10:
Accepted.
Comment #11:
The Committee considered that this would be too difficult
to provide on many implementations. There were also technical
flaws in the proposal.
Comment #12:
Duplicated of Norway #12.
Comment #13:
Duplicated of US-1 Walls #1
Comment #14:
The Committee has voted for this idea.
US-16 (John Hauser)
Comment #1:
Accepted. See the response to US-2 Comment #2.
Comment #2:
Moving the formulas into normative text might lead users to
believe the functions are required to be implemented by the
formulas. The association of "the usual mathematical formulas"
in normative text to the formulas in the footnote is clear enough.
Comment #3:
Accepted as editorial.
Comment #4:
Accepted as editorial.
Comment #5:
A bullet will be added to G.5.2.3 to cover the missing case:
-- catanh(1+i0) returns +infinity+i0 and raises the
divide-by-zero exception
Although the imaginary part is indeterminate, 0 was chosen so the
function will equal the real atanh function on the x axis, in keeping
with the general approach for complex special cases, e.g. in the
specification for clog(0+i0).
Comment #6:
The draft will be changed to incorporate the suggested fix.
Comment #7:
In G.5.2.6, the bullet
-- ctanh(+inf+iy) returns 1+i0, for all positive-signed numbers y
will be replaced by the first two suggested bullets in the comment.
The remaining suggestions in this comment were not accepted
because the refinements
ctanh(+0+i*inf) = +0+i*NaN
ctanh(+0+i*NaN) = +0+i*NaN
would be problematic due to the possible 0/0 indeterminacy in
the real part of ctanh(x+i*y):
sinh(2x) / (cosh(2x) + cos(2y))
when cos(2y) =-1.
Comment #8:
Editorial. Typo. Already fixed.
Comment #9:
The comment reflects a good understanding of the thinking
underlying the specification of complex special cases. We
should add that even if the partial information represented by
a special-case non-NaN value is lost in subsequent calculations,
the value still may be more useful than a NaN. In a significant
number of calculations, the actual numerical value of one part or
the other of an intermediate complex value doesn't matter, but a
NaN value in that part would cause an undesirable NaN in the
final result. The computation of a cube root as w = cexp(clog(z)/3)
illustrates the point, as z = 0+0i would yield w = NaN+iNaN if
carg(z), and hence the imaginary part of clog(z), were required to
be a NaN. In such cases the programmer is spared the burden for
coding to defend against certain inputs, and the program is more
efficient. The programmer guarding against bad inputs will be no
worse off with the current specification.
Admittedly the current specification entails some risk for non
defensive programmers, who might gain some benefit from a
NaN result giving an after-the-fact indication of a problem. This
benefit is thought less than might first appear because the programs
that could benefit are likely to first encounter erroneous calculations
that don't produce NaNs, e.g. carg(z) may be questionable if z is
very small but not 0.
Even though the suggested specification would be more helpful in
some instances, the approach of allowing two treatments of the
contentious cases was rejected for portability reasons.
US-17 (Paul Eggert)
Comment #1:
The Committee considered that there were good reasons to
leave this choice for implementations.
Comment #2:
The Committee has voted for this idea.