Subject: SC22 N2898 - Comments Disposition for FCD 9899 - C

From: William Rinehuls <[email-masked]>
Date: Thu, 11 Mar 1999 18:06:44 -0500 (EST)

__________________ beginning of title page ___________________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22
N2898

TITLE:
Disposition of Comments Report for Final CD (FCD) 9899 - Information
technology - Programming languages - Programming Language C (Revision of
ISO/IEC 9899:1990)

DATE ASSIGNED:
1999-03-11

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Disposition of Comments Report

PROJECT NUMBER:
JTC 1.22.20.01

STATUS:
N/A

ACTION IDENTIFIER:
FYI

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
N2872

DISTRIBUTION FORM:
Def

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone:  +1 (703) 912-9680
Fax:  +1 (703) 912-2973
email:  [email-masked]

__________ end of title page; beginning of report ______________________

              Disposition of Comments Report for FCD 9899
Information technology - Programming languages - Programming Language C

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.

______________________ end of SC22 N2898 _____________________________