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 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 ). 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 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 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 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.