ISO/ IEC JTC1/SC22/WG14 N799





                                                     SC22/WG14 N799
       Editor's Report



                                                    January 2, 1998



       1.  Status

       As  you know, an editorial committee consisting primarily of
       Benito, Farance, Jaeschke, Jones, MacDonald, and Walls (with
       the  assistance  of  Thomas,  Gwyn, and others) met in Santa
       Cruz November 17-20 to prepare  the  draft  for  CD  ballot.
       After   much   work  at  the  meeting  and  some  subsequent
       formatting  clean-up,  a  final  document  was  prepared  on
       November 24 and forwarded to SC22.  A preliminary version of
       this draft was distributed (via the committee's web page) as
       N794;   this   document  has  been  circulated  outside  the
       committee as well as within it  and  has  generated  a  fair
       amount  of discussion on the comp.std.c newsgroup as well as
       some private e-mail pointing out errors and omissions.   The
       remainder  of this report is based on these comments as well
       as my own review.


       2.  CD1 Errata

       General

       All of the headings are too small.  When  the  size  of  the
       body  text was increased, the sizes of the headings were not
       increased to match.

       General

       None of the  tables  are  properly  formatted  in  the  text
       version due to a production error.

       General

       There  are  many  typesetting  issues still to be addressed.
       For example, there are many equations typeset  as  code  and
       vice  versa, particularly in annexes F and G.  Some of these
       issues  primarily  affect  the  typeset  version  and   some
       primarily affect the text version.

       General

       The   term   ``universal-character-name''   should   not  be
       hyphenated (other than in the syntax).

       Clause 3, Paragraph 2, Page 3

       The reference to ISO 2382-1 should be to ISO/IEC 2382-1.




       SC22/WG14 N799                                             2


       5.1.1.2, Forward References, Page 10

       There should be a forward reference to 5.2.1  for  universal
       character names.

       5.1.2.3, Example 6, Page 16

       ``However''  (4th line from the end) should be followed by a
       comma.

       5.2.1.1, Footnote 12, page 19

       The reference to ISO/IEC 646:1991 should be to ISO 646.

       5.2.4.2.2, Paragraph 6, Page 26

       The list of values  should  be  indented  like  the  one  in
       paragraph 5.

       6.1 and 6.2, Pages 31-66

       The reorganization specified in N672 has not been applied.

       6.1.2, Paragraph 2, Page 34

       The reference to annex H should be to annex I.

       6.1.2.5, Footnote 30, Page 40

       In  the last line, there should not be a comma after ``two''
       and ``it'' should be ``is''.

       6.1.2.6, Paragraph 1, Page 42

       Near the end of the fifth line, the period after ``following
       requirements'' should be a colon.

       6.1.4, Paragraph 6, Page 55

       Although  this  paragraph  doesn't  contain  the  magic word
       ``unspecified'', whether string literals are distinct or not
       is unspecified and should be added to K.1.

       6.1.5, Paragraph 1, Page 55

       The  definition  of operator is missing { and }, although it
       does have the  alternative  spellings   <:  and   :>.   They
       should also appear in the constraint.  (Also annex B.)

       6.1.6, Paragraph 1, Page 56

       The  definition of punctuator is missing ..  (Also annex B.)




       3                                             SC22/WG14 N799


       6.2.1.1, Paragraph 2, Page 60

       The period after ``may be used'' should be a colon.

       6.2.1.3, Footnote 48, Page 61

       In the last line, there should be a space after the comma.

       6.3.2.2, Paragraphs 5-6, Page 72

       These paragraphs are almost impossible  to  read  correctly.
       At  the  very least, paragraph 6 should be a continuation of
       paragraph 5, not a new paragraph.  My suggestion is to  keep
       paragraph  6 and move the end of paragraph 5 starting at the
       fifth line (``If the function is defined...'')  to  the  end
       of paragraph 6.

       6.3.2.5, Example 5, Page 78

       In the last line of code, there should be a space before the
       square brackets.

       6.3.3.3, Paragraphs 2-4, Page 81

       In each paragraph, ``the integer promotion  is''  should  be
       ``the integer promotions are''.

       6.3.6, Paragraph 12, Page 87

       In line 2, ``know constant size'' should be ``known constant
       size''.

       6.3.15, Paragraphs 4-6, Page 93

       The last clause of paragraph 4 should read:

            the result of the operator is  the  value  of  the
            second  or third operand (whichever is evaluated),
            converted to the type described below.

       The first sentence of paragraph 5 should read:

            If  both  the  second  and  third  operands   have
            arithmetic   type,   the   type   that  the  usual
            arithmetic conversions would yield if  applied  to
            those two operands is the type of the result.

       The  last  sentence  of  paragraph 6 should read: ``in which
       case the type of the result is pointer to void.''

       6.5.2, Paragraph 4, Page 103

       In the middle of the second line,  ``specified''  should  be
       ``specifier''.




       SC22/WG14 N799                                             4


       6.5.2.3, Paragraph 3, Page 108

       In the second line, ``complete'' should be ``incomplete''.

       6.6.4.1, Paragraph 3, Page 142

       In  the  first line, ``preceeding'' should be ``preceding''.
       (And I'd be grateful if  anyone  could  explain  to  me  why
       ispell doesn't complain about it.)

       6.6.6.1, Example 2, Page 146

       In the middle of the block of code, the line ``goto lab 4;''
       should be ``goto lab4;''.

       6.8.8, Paragraph 1, Page 170

       It might be clearer to specify that  __LINE__  is  the  line
       number  within  the current source file and that __FILE__ is
       the name of the current source file.

       6.8.8, Paragraph 2, Page 171

       The second line should not appear and the remainder  of  the
       paragraph  should  be  formatted  as  definitions  as in the
       previous paragraph.

       6.8.9, Paragraph 1, Page 172

       In the third line, the period after ``follows'' should be  a
       colon.

       6.8.9, Examples, Paragraph 2, Page 172

       In the #pragma, ``list'' should be ``listing''.

       7.1.2, Paragraph 1, Page 175

       In the last line, ``explicity'' should be ``explicitly''.

       7.1.7, Paragraph 2, Page 179

       In the last line, ``for'' should be ``of''.

       7.1.8, Paragraph 3, Page 181

       ``return'' should be ``returns''.  (Also annex C.)

       7.2.1.1, Paragraph 2, Page 183

       In  line  4,  ``name of the source file, and the source line
       number'' should be ``name of the  source  file,  the  source
       line number, and the name of the enclosing function''.




       5                                             SC22/WG14 N799


       7.3.1.3, Page 186

       The  isblank  function was not approved by the committee and
       should not have appeared in the draft.

       7.4, Paragraph 3, Page 190

       Starting  at  the  end  of  the  first   line,   ``character
       constants'' should be ``constants''.

       7.4.5, Paragraph 1, Page 199

       The reference to footnote 151 should be to 149 instead.

       7.5, Paragraph 3, Page 202

       The  reference to footnote 153 should be moved to the end of
       the sentence.

       7.5.1, Paragraph 2, Page 203

       In the very last  line,  there  should  be  a  reference  to
       strfxtime as well as strftime.

       7.7.8.3, Paragraph 3, Page 236

       In the last line, ``too large'' should be ``too large or too
       small''.

       7.11, Paragraph 3, Page 266

       The portion of the paragraph between the  two  lists  should
       read:

            which expand to constant expressions with distinct
            values that have type compatible with  the  second
            argument to, and the return value from, the signal
            function, and whose values compare unequal to  the
            address   of  any  declarable  function;  and  the
            following,  which  expand  to   positive   integer
            constant  expressions  with  type int and distinct
            values that are the signal numbers...

       7.13.6.1, Paragraph 3, Page 288

       In the list item beginning ``An optional hh...'', the  words
       for hhn have been omitted.

       7.13.6.1, Paragraph 14, Page 293

       The header should read "Environmental limits".




       SC22/WG14 N799                                             6


       7.13.6.2, Paragraph 11, Pages 297-298

       In  the descriptions of the s,  [, and  c format specifiers,
       there should not be a paragraph break before  the  paragraph
       beginning ``If an l qualifier is present...''.

       7.14.5, Footnote 227, Page 336

       The last line of the footnote is missing.  It should read:

            (char *)p < (char *)base + nmemb * size

       7.16.1, Paragraph 1, Page 357

       In  the  first  line,  ``four  types and several functions''
       should be ``several types and functions''.

       7.16.2.3, Paragraphs 5-6, Page 360

       The last line of paragraph 5 and all of paragraph  6  should
       be deleted.

       7.16.2.6, Paragraph 3, Page 363

       At  the end of the block of // comments, there should be one
       more:

            // if the offset cannot be determined.

       7.16.3.6, Paragraph 6, Page369

       ``%P'' should be ``%p'' and "am" and "pm" should not  be  in
       program font.

       7.18.2.1.1, Paragraph 2, Page 373

       ``Th'' should be ``The''.

       7.18.2.1.3, Page 373

       The  iswblank function was not approved by the committee and
       should not have appeared in the draft.

       7.18.2.2, Paragraph 1, Page 376

       The reference to subclause 4.5.2.1 should be to 7.18.2.1.

       7.19.2.1, Paragraph 2, Page 381

       The last sentence is duplicated.

       7.19.2.1, Paragraph 2, Page 382

       In the list item beginning ``An optional hh...'', the  words




       7                                             SC22/WG14 N799


       for hhn have been omitted.

       7.19.2.1, Paragraph 14, Page 388

       The header should read "Environmental limits".

       7.19.2.1, Paragraph 16, Page 388

       This  should  be a normal Forward References section  --  it
       should not have a paragraph number and the header should  be
       in bold font.

       7.19.2.2, Paragraph 11, Pages 391

       In  the  second  line  of  the  description  of the [ format
       specifier, ``f'' should be ``If''.

       7.19.2.2, Paragraph 11, Pages 391-392

       In the descriptions of the s,  [, and  c format  specifiers,
       there  should  not be a paragraph break before the paragraph
       beginning ``If an l qualifier is present...''.

       7.19.2.2, Examples, Page 393

       There should not be numbered paragraphs in the examples.

       7.19.2.2, Paragraph 22, Page 394

       This should be a normal Forward References section   --   it
       should  not have a paragraph number and the header should be
       in bold font.

       7.19.7.3.1, Paragraph 4, Page 426

       This should be a normal Forward References section   --   it
       should  not have a paragraph number and the header should be
       in bold font.

       7.19.7.3.3, Paragraph 3, Page 426

       ``a value between'' should be ``or a value between''.

       Annexes

       The annexes and the index are all formatted wider  than  the
       main text.

       Annex A, Page 434

       The hyphens in the standards' designations should be dashes.




       SC22/WG14 N799                                             8


       F.9.3.11, Paragraph 1, Page 501

       In the second bullet item, there should be a space between )
       and ``returns''.

       G.5, Paragraph 5, Page 514

       The reference to subclause 7.9.2 should be to 7.8.2.

       Index, Pages 559-570

       The  index,  which was produced manually, is both incomplete
       and inaccurate.  I have since reviewed and corrected it  and
       used  that  information  to  continue  the process of adding
       index macros to  the  text  so  as  to  generate  the  index
       automatically  as  part  of  the formatting process.  I have
       also added the automatic index generation to the  formatting
       process and have produced an enhanced and corrected index to
       CD1 (N800) which can be used to aid in the review process.

       Note that there is still a lot of work to  be  done  on  the
       index;  I  would  appreciate  any suggestions for additional
       entries, additional cross references, missing references, or
       excessive references.


       3.  Suggested Editorial Changes

       General

       All  hyphenated  terms should be examined to determine where
       the hyphenation is appropriate  and  where  it  isn't.   All
       italicized terms should also be examined.

       General

       References  to  other  standards should not include specific
       versions except in the References and Bibliography.

       5.1.1.2, Paragraph 6, Page 9

       Since we now  allow  concatenation  of  character  and  wide
       string  literals,  this  paragraph  should  be  rewritten to
       simply:

            Adjacent string literal tokens are concatenated.

       5.2.1  Paragraph 4, Page 16

       Universal character names should have  their  own  subclause
       (like trigraphs do).

       I also suggest changing the description to:




       9                                             SC22/WG14 N799


            The universal character name \Unnnnnnnn designates
            the character whose character short identifier (as
            specified   by   ISO/IEC   10646-1)  is  nnnnnnnn.
            Similarly, the  universal  character  name  \unnnn
            designates  the  character  whose  character short
            identifier is 0000nnnn.

       5.2.4.2.2, Paragraph 9, Page 28

       A better wording is:

            The values given in the following  list  shall  be
            replaced   by  implementation-defined  expressions
            with [positive?] values  that  are  less  than  or
            equal to those shown:

       6.1.2.5, Footnote 29, Page 40

       I suggest rewording the first two sentences to:

            An  implementation  may  define  new keywords that
            provide alternative ways to designate a basic  (or
            any   other)  type;  this  does  not  violate  the
            requirement that all basic types be different.

       6.1.3.1, Paragraph 1, Page 47

       The  definition  of  hexadecimal  digit  really  belongs  in
       6.1.3.2  (Integer  constants)  since  there  is  text  there
       explaining it.  It would perhaps be best to switch these two
       sections.

       6.1.3.4, Paragraph 5, Page 50

       The  lists  of  types  for constants would be much easier to
       read as a table.

       6.5.2.2, Paragraph 5, Page 108

       It would be better to say:

            The type is incomplete  until  after  the  }  that
            terminates the list.

       since  that's what we say for structure and union specifiers
       (cf., 6.5.2.1, Paragraph 6, Page 104).

       Clause 7

       Many of the subclauses should be rearranged to put them into
       alphabetical order.




       SC22/WG14 N799                                            10


       7.4.5, Paragraph 1, Page 199

       Since  footnote 149 (which is what this is supposed to refer
       to) is so far away, it should be  replicated  here  or  this
       subclause should be moved to immediately after 7.4.2.

       7.7, various

       A  number  of subclauses in this section write out equations
       using words such as ``x raised to the power y''.  I  suggest
       using equations in all cases.

       7.7.6.5, Paragraphs 2-3, Page 230

       This  subclause  uses  ``base-ten'',  other  subclauses  use
       ``base-2'';  we  should  be  consistent.   I  suggest  using
       numbers everywhere.

       7.13.3, Paragraph 7, Page 279

       Since  this paragraph is talking about the standard streams,
       it might be better to move it to subclause 7.13.2 (Streams).

       7.16.2.4, Paragraph 2, Page 361

       At  the  end  of  the  line,  ``takes  into  account  of the
       additional members'' should  be  ``takes  into  account  the
       values of the additional members''.

       7.18.2.1, Paragraph 2, Page 372

       In  the  second  line, it would be better to not mention the
       exact number of functions (it's easy to overlook if the list
       ever  changes).   Similarly for 7.18.2.2.1 paragraph 3 (page
       376) and 7.18.2.2.2 paragraph 3 (page 377).

       H.2.4, Paragraph 1, Page 525

       The ugly arrows should be replaced by real arrows.

       K.2, Page 537, Bullet 3

       Similarly, converting between a  pointer  to  an  object  or
       incomplete type and a pointer to a function causes undefined
       behavior.  Subclause 6.2 is also relevant.

       K.2, Page 537, Bullet 12

       It should be clarified that this only applies to  relational
       comparisons, not equality comparisons.

       K.2, Page 538, Bullet 14

       I think what this is supposed to say is ``An attempt is made




       11                                            SC22/WG14 N799


       to  access  an  object  through  both  a  restrict-qualified
       pointer and another pointer not based on it.''


       4.  Suggested Possibly-substantive Changes

       3.18, Paragraph 3, Page 6

       An  implementation  need  not successfully translate a given
       program if it exceeds a translation limit.

       6.1.3.1, Paragraph 1, Page 47

       In  the  first  two  productions  for  hexadecimal  floating
       constant,  the  binary  exponent  part  should  be  optional
       (parallel to decimal floating constant).


       5.  Open Issues

       Clause 4, Paragraph 2, Page 7

       Should <stdbool.h> be added to the list of required  headers
       for freestanding implementations?

       6.1, Paragraph 3, Page 31

       Are all the italicized terms really appropriate?

       6.1.3.1, Paragraph 1, Page 47

       The 0x and 0X prefixes are used in multiple places, it might
       simplify the grammar to  factor  them  out  into  their  own
       nonterminal.

       Clause 7

       There are no synopses for the float and long double versions
       of the math routines and there are a number of synopses that
       basically  duplicate  or refer to other synopses.  We should
       consider  allowing  multiple  synopses  for  a   family   of
       functions  with a single description like the Unix man pages
       have traditionally done.

       7.7.11.2, Paragraph 2, Page 242

       It is not clear what the last line  (``a  call  to  the  nan
       function is unspecified'') is supposed to mean.

       7.11.2.1, Paragraph 3, Page 268

       It  is  not  clear  when  the raise function is permitted to
       fail; is it only for an invalid signal number or  are  there
       other conditions?




       SC22/WG14 N799                                            12


       7.13.5.2, Paragraph 4, Page 283

       It is not clear what happens if stream is a null pointer and
       a write error occurs on one of the streams being flushed.

       7.13.6.2, Paragraph 11, Page 298

       In the description of the [ conversion specifier, it is  not
       clear  whether  the  scanset  is  composed  of  single  byte
       characters or multibyte characters.

       7.14.3.4, Paragraph 3, Page 334

       The comparison described in the  last  sentence  results  in
       undefined behavior if the object has moved.

       7.16.1, Paragraph 4, Page 358

       It  is  not always clear what happens if a member is outside
       its normal range when calling functions in the subclause.

       7.18.2.1, Pages 372-377

       Many of these functions provide very little guidance  as  to
       their  intended  semantics other than the similarity between
       their  names  and  the  names  of  the  ordinary   character
       functions.   It  seems like we should say a bit more than we
       currently do.

       Annex F

       There are no entries for ilogb, scalbln, llrint, llround, or
       nextafterx.   We should say something about them, just so it
       doesn't look like an oversight.

       K.2, Page 535, Bullet 4

       The first character of an identifier can't be a  digit,  the
       syntax doesn't allow it.

       K.2, Page 540, Bullet 10

       This  isn't  undefined behavior.  I think the situation that
       this is supposed to be  describing  is  that  when  a  macro
       expansion  ends with a macro name which is ``painted blue'',
       and that macro is a function-like macro, and the first token
       of the remaining source-file tokens is a (, it was not clear
       whether that macro was to be replaced or not and thus it was
       undefined behavior to depend on one or the other.

       Rereading the subclause on rescanning again, it now looks to
       me like it is  clearly  specified  that  the  macro  is  not
       replaced.  Does anyone disagree?




       13                                            SC22/WG14 N799


       --                            Larry Jones