ISO/ IEC JTC1/SC22/WG14 N804





                                                     SC22/WG14 N804
       Editor's Report



                                                   January 30, 1998



       This  is a revised version of N799 incorporating corrections |
       and additions.  The diff marks  indicate  changes  from  the |
       original version.


       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.  That document has since |
       been distributed to the members of SC22 and  made  available |
       on  SC22's  web  page.  Various member bodies have announced |
       its  availability  and   solicited   public   comments.    A |
       preliminary  version  of  the draft was distributed (via the |
       committee's web page) as N794; this document has  also  been |
       circulated outside the committee as well as within it.  Both |
       documents have generated a fair amount of discussion on  the |
       comp.std.c  newsgroup and the committee reflector 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.                                          |

       None of the  tables  are  properly  formatted  in  the  text
       version  due  to  a production error.  (The text version has |
       not  been  reviewed  and  undoubtedly  contains  many  other |
       formatting problems.)                                        |

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

       Clause 2, Paragraph 1, Page 2                                |




       2                                             SC22/WG14 N804


       Although  one  of  the references is a technical report, the |
       introductory text refers only to  standards;  it  should  be |
       revised to include TRs.                                      |

       The hyphens in the standards' designations should be dashes. |
       This  is  also  true  for  other  references  in  the  text, |
       particularly annex A.                                        |

       The  correct date for ISO 4217 is 1995, the correct date for |
       ISO/IEC TR 10176 is 1998 (also annex A).

       Clause 3, Paragraph 2, Page 3

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

       3.18, Paragraph 3, Page 6                                    |

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

       5.1.1.2, Paragraph 1, Page 9                                 |

       The   term   ``universal-character-name''   should   not  be |
       hyphenated.  This is also true  for  all  other  occurrences |
       (other than in the syntax).                                  |

       Since  we  now  allow  concatenation  of  character and wide |
       string literals, phase 6 should be rewritten to simply:      |

            Adjacent string literal tokens are concatenated.

       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.




       SC22/WG14 N804                                             3


       6.1.2, Paragraph 2, Page 34

       The  description of nondigit characters should mention other |
       characters specified by universal character names.           |

       The reference to annex H should be to annex I.               |

       6.1.2.5, Footnote 29, Page 40                                |

       In the second line, ``alternate'' should be  ``alternative'' |
       and   ``designed''   should  be  ``designate''.   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.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 2, Page 54                                  |

       The  terms  ``character  string  literal'' and ``wide string |
       literal'' should be in italics.

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

       6.2.1.1, Paragraph 2, Page 60

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



       4                                             SC22/WG14 N804


       6.2.1.3, Footnote 48, Page 61

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

       6.3.1.1, Page 69                                             |

       In  the  heading,  there  should be a thin space between the |
       underscores.

       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  move |
       paragraph  6  into  paragraph 5 between the third and fourth |
       sentences.   I  also  suggest  moving  paragraph   7   after |
       paragraph 8.

       6.3.2.5, Example 5, Page 78

       In the last line of code, there should be a space before the
       square brackets.  Likewise for example 6.                    |

       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.

       Paragraph  6,  beginning  with  the  second sentence, should |
       read:                                                        |




       SC22/WG14 N804                                             5


            Furthermore, if  both  operands  are  pointers  to
            compatible types or differently qualified versions
            of compatible types, the result type is a  pointer
            to  an  appropriately  qualified  version  of  the
            composite type; if one operand is a  null  pointer
            constant,  the  result  has  the type of the other
            operand; otherwise, one operand is  a  pointer  to
            void or a qualified version of void, in which case
            the result type is a pointer to  an  appropriately
            qualified version of void.

       6.5, Paragraph 1, Page 100                                   |

       The last production for declaration-specifiers should read:  |

            function-specifier declaration-specifiers-opt

       6.5.2, Paragraph 4, Page 103

       In  the  middle  of the second line, ``specified'' should be |
       ``specifier''  and  ``is   the   same   type''   should   be |
       ``designates the same type''.                                |

       6.5.2.1, Footnote 91, Page 105                               |

       The  remnants  of  implicit  int should be removed; the body |
       should read:                                                 |

            As specified in 6.5.2 above, if  the  actual  type
            specifier used is int or a typedef-name defined as
            int, then it is implementation-defined whether the
            bit-field is signed or unsigned.

       6.5.2.3, Paragraph 3, Page 108

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

       6.5.2.3, Paragraph 6, Page 109                               |

       The  declaration  is  missing the trailing semicolon and, in |
       the last line, ``structure of union'' should be  ``structure |
       or union''.

       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                                             SC22/WG14 N804


       6.6.6.2, Paragraph 2, Page 147                               |

       The statements in the code blocks are not properly  aligned.

       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 and ``string literal'' should not be italicized.

       6.8.9, Examples, Paragraph 2, Page 172

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

       7.1.1, Paragraph 1, Page 174                                 |

       The quoted terms should all be italicized (cf. paragraph 6).

       7.1.2, Paragraph 1, Page 175

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

       7.1.7, Page 179                                              |

       Still  need  final  words  for a real boolean type (N738 and |
       part of N743 were adopted in principle, but no  final  words |
       were ever produced).

       7.1.7, Paragraph 2, Page 179

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

       7.1.7, Footnote 138, Page 179                                |

       In the second paragraph, the quotes around ``masked'' should |
       be real quotes, not double-quotes.

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

       7.3.1.3, Page 186




       SC22/WG14 N804                                             7


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

       7.4, Paragraph 1, Page 190                                   |

       There  should  be  a  footnote  pointing  to  future library |
       directions (7.20.3).

       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. |
       Since footnote 149 is so far away, I suggest replicating  it |
       here or moving this subclause to immediately after 7.4.2.

       7.5, Paragraph 3, Page 202

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

       7.5.1.1, Paragraph 2, Page 203                               |

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

       7.7.8.3, Paragraph 2, Page 236                               |

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

       7.7.9.3, Paragraph 2, Page 238                               |

       The parenthetical sentence  at  the  end  of  the  paragraph |
       should  be  included in the previous sentence and the hyphen |
       should be the word ``and''.                                  |

       7.8, Paragraph 1, Page 249                                   |

       There should  be  a  footnote  pointing  to  future  library |
       directions (7.20.8).                                         |

       7.8.2.23, Paragraph 2, Page 258                              |

       There should be a reference back to footnote 188.            |

       7.10.2.1, Paragraph 2, Page 264                              |

       The comma near the end of the second line should be deleted. |
       It implies that you can only  longjmp  to  the  most  recent |
       setjmp, which is clearly not correct.




       8                                             SC22/WG14 N804


       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 of,  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.11.1.1, Paragraph 3, Page 267                              |

       In the fourth line, ``occuring'' should be ``occurring''.    |

       7.13.2, Paragraph 5, Page 277                                |

       In  the  first  line, there should not be a semicolon before |
       ``and''.                                                     |

       In the third line, the phrase ``and are  not  affected  by'' |
       should be set off by commas.                                 |

       7.13.2, Forward references, Page 278                         |

       The  entries  should  be the actual section titles, not just |
       the names of the functions.                                  |

       7.13.3, Paragraph 11, Page 279                               |

       ``getwc'' should be ``fgetwc''.                              |

       7.13.3, Forward references, Page 280                         |

       The reference for ``conversion state'' should be 7.19.6, for |
       mbrtowc  should  be  7.19.6.3.2,  and  for wcrtomb should be |
       7.19.6.3.3.

       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 3, Page 291                              |

       In the description of the c conversion specifier, at the end |
       of the second  line,  ``Otherwise''  should  be  ``If  an  l |
       qualifier  is  present''  and  should  start a new paragraph |
       (cf., the s conversion specifier).                           |




       SC22/WG14 N804                                             9


       7.13.6.1, Footnote 213, Page 292                             |

       The reference should be to 7.20.6.

       7.13.6.1, Paragraph 14, Page 293

       The heading should read "Environmental limits".              |

       7.13.6.2, Paragraph 11, Pages 297-298

       In  the  descriptions  of  the  s,   [,  and   c  conversion |
       specifiers,  there  should  be  a paragraph break before the |
       sentence beginning ``If no l qualifier is present...''.      |

       The reference to footnote 216 should be  replicated  in  the |
       descriptions of the [ and c conversion specifiers.           |

       7.13.6.2, Footnote 216, Page 297                             |

       There should be an ``and'' before c.                         |

       7.13.6.2, Footnote 217, Page 299                             |

       The reference should be to 7.20.6.                           |

       7.13.6.2, Example 3, Page 301                                |

       The last block of code is too wide; it should be reformatted |
       to fit within the margin.                                    |

       7.13.7.11, Paragraph 5, Page 314                             |

       There should be a footnote  at  the  end  of  the  paragraph |
       pointing to ``future library directions'' (7.20.6).          |

       7.14, Footnote 221, Page 321                                 |

       The reference should be to 7.20.7.                           |

       7.14.2.1, Paragraph 5, Page 330                              |

       The heading should read "Environmental limits".

       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.15.1, Footnote 232, Page 345                               |

       The reference should be to 7.20.9.




       10                                            SC22/WG14 N804


       7.16.1, Paragraph 1, Page 357

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

       7.16.1, Paragraph 3, Page 357                                |

       The wording for struct tm and struct tmx should  be  revised |
       to clarify that both hold broken-down times.

       7.16.2.3, Paragraphs 5-6, Page 360

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

       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.16.2.5, Paragraph 2, Page 362                              |

       ``L'' should be italicized throughout this paragraph.

       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, Paragraphs 2-6, Pages 367-369                      |

       The  typography  throughout  this  section  is inconsistent, |
       particularly the use of program font and double-quotes;  the |
       use of == in paragraph 3 is also unconventional.             |

       The hyphens in the range specifications should be dashes.    |

       7.18.1, Paragraph 2, Page 371                                |

       At the end of the description of wint_t, there should not be |
       a period before the parenthetical remark, the  parenthetical |
       remark should not start with an upper case letter and should |
       not end with a period, and a  semicolon  should  follow  the |
       parenthetical remark.                                        |

       At the end of the description of wctrans_t, the comma should |
       be a semicolon.                                              |

       7.18.1, Footnote 241, Page 371                               |

       The reference should be to 7.20.10.                          |




       SC22/WG14 N804                                            11


       7.18.2.1, Paragraph 3, Page 372                              |

       This should be a normal Forward References section   --   it |
       should not have a paragraph number and the heading should be |
       in bold 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.1, Footnote 247, Page 380                               |

       The reference should be to 7.20.11.                          |

       7.19.1, Paragraph 2, Page 380                                |

       The  comma  at  the  end  of  the  first  line  should  be a |
       semicolon.                                                   |

       7.19.1, Paragraph 3, Page 380                                |

       The comma near the  end  of  the  third  line  should  be  a |
       semicolon and there should not be a paragraph number.        |

       7.19.1, Paragraph 4, Page 380                                |

       The  period  at  the  end  of the line should be a semicolon |
       followed by ``and'' and there  should  not  be  a  paragraph |
       number.                                                      |

       7.19.1, Paragraph 5, Page 380                                |

       There should not be a paragraph number and this should read: |

                 struct tm

            and

                 struct tmx

            which are declared as incomplete structure  types,
            the  contents  of which are described in subclause
            7.16.1.




       12                                            SC22/WG14 N804


       7.19.1, Paragraph 6, Page 380                                |

       The comma  at  the  end  of  the  first  line  should  be  a |
       semicolon.                                                   |

       7.19.1, Paragraph 7, Page 380                                |

       The comma at the end of the first line should be a semicolon |
       and there should not be a paragraph number.                  |

       7.19.1, Paragraph 8, Page 380                                |

       The comma near the  end  of  the  first  line  should  be  a |
       semicolon  and  should  not  be  in  program font, and there |
       should not be a paragraph number.                            |

       7.19.1, Paragraph 9, Page 380                                |

       There should not be a paragraph number.

       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
       for hhn have been omitted.                                   |

       7.19.2.1, Paragraph 7, Page 386                              |

       In  the  description of the c conversion specifier, near the |
       beginning of the third line, ``Otherwise'' should be ``If an |
       l  qualifier  is  present'' and should start a new paragraph |
       (cf., the s conversion specifier).                           |

       7.19.2.1, Footnote 255, Page 387                             |

       The reference should be to 7.20.11.

       7.19.2.1, Paragraph 14, Page 388

       The heading 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 heading should be |
       in bold font.

       7.19.2.2, Paragraph 11, Pages 391-392

       In  the  descriptions  of  the  s,   [,  and   c  conversion |
       specifiers,  there  should  be  a paragraph break before the |




       SC22/WG14 N804                                            13


       sentence beginning ``If no l qualifier is present''.         |

       In the  description  of  the  s  conversion  specifier,  the |
       paragraph  beginning  ``Otherwise''  should  begin ``If an l |
       qualifier is present'' (cf., the [ conversion specifier).    |

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

       7.19.2.2, Footnote 258, Page 392                             |

       The reference should be to 7.20.11.

       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 heading should be |
       in bold font.                                                |

       7.19.4.6.2, Paragraph 1, Page 421                            |

       The  prototype  is not parallel to memcmp; neither s1 nor s2 |
       should be restrict qualified, and s1 should be a pointer  to |
       const.                                                       |

       7.19.5 and 7.19.6, Pages 422-423                             |

       These  should  be  sub-subclauses  of a new subclause titled |
       ``Wide-character time conversion functions''.                |

       7.19.7.3.1, Paragraph 3, Page 426                            |

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

       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 heading should be |
       in bold font.                                                |

       7.20.11, Paragraph 2, Page 433                               |

       Should note that other characters may be used in  extensions |
       (cf., 7.20.6, paragraph 1, page 432).

       Annexes

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



       14                                            SC22/WG14 N804


       Annex C, Paragraph 2, Page 451                               |

       There should also be entries for the sequence points  within |
       library functions specified in 7.13.6, 7.19.2, and 7.14.5.   |

       F.1, Paragraph 1, Page 485                                   |

       The  standards'  designations should not be in italics, only |
       the titles.                                                  |

       F.1, Footnote 275, Page 488                                  |

       Both occurrences of ``IEEE'' should be ``ANSI/IEEE''.

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

       Annex H, Pages 522-527                                       |

       The hyphen in ``LIA-1'' should be a dash.                    |

       H.2.2, Paragraphs 1 and 3, Page 522                          |

       The double-quotes should be real quotes.                     |

       H.2.4, Paragraph 1, Page 525                                 |

       The ugly arrows should be replaced by real arrows.           |

       There  should  not  be  spaces  between  the  casts  and the |
       variable names.                                              |

       K.2, Page 539, Item 3                                        |

       The reference should be to 6.5.5.3 (and the item  should  be |
       moved in the list appropriately).                            |

       K.2, Page 544, Item 5                                        |

       strfxtime,  wcsftime,  and  wcsfxtime  should  be  listed in |
       addition to strftime.  (Similar changes to page 545 items  1 |
       and  7, and page 547 items 1 and 2; and K.3.12 page 554 item |
       6.)                                                          |

       K.4, Page 555                                                |

       In item 8, isblank (7.3.1.3) should not appear in the  list. |




       SC22/WG14 N804                                            15


       In  item  18, iswblank (7.18.2.1.3) should not appear in the |
       list.

       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

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

       3.17, Paragraph 1, Page 5                                    |

       I  think this would read better if ``specification that is'' |
       was changed to ``specifications that are''.  (Also in  other |
       places, particularly annexes F and G.)                       |

       5.1.1.2, Paragraph 2, Page 10                                |

       This  is a peculiar place for a constraint since there is no |
       syntax for it to constrain.  It should be moved to where the |
       syntax is, currently 5.2.1 on page 19.                       |

       5.2.1  Paragraph 4, Page 19                                  |

       This  is  a  peculiar place to have syntax, since the syntax |
       isn't even described until clause 6.  I suggest leaving  the |
       first  sentence  here  but  moving  the  syntax  and  all of |
       paragraph 5 (along with the related constraint from 5.1.1.2) |
       into 6.1.2 (Identifiers).

       I also suggest changing the description to:

            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




       16                                            SC22/WG14 N804


            identifier is 0000nnnn.

       5.2.4.2.2, Paragraph 7, Page 26                              |

       A better wording is:                                         |

            The values given in the following  list  shall  be
            replaced   by  implementation-defined  expressions
            with values that are greater or equal in magnitude
            (absolute  value)  to  those  shown, with the same
            sign:

       5.2.4.2.2, Paragraph 8, Page 27                              |

       A better wording is:                                         |

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

       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:

       Note that ``positive'' is implied by the float-point  model, |
       but it might be worth repeating.                             |

       6.1.1, Paragraph 2, Page 33                                  |

       When  discussing  imaginary,  I think it would be clearer to |
       say:

            ... the token imaginary is reserved in translation |
            units where the header <complex.h> is included and |
            defines the macro _Imaginary_I;

       The current wording implies that the program needs to define |
       _Imaginary_I rather than the header.

       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




       SC22/WG14 N804                                            17


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

       6.3.5, Paragraph 7, Page 84                                  |

       This paragraph should be merged with paragraph 3.            |

       6.3.6, Paragraph 10, Page 86                                 |

       This paragraph should be merged with paragraph 4.            |

       6.4, Footnote 84, Page 98                                    |

       Since   the  footnote  only  talks  about  integer  constant |
       expressions, it would be better to  have  the  reference  on |
       that  term in paragraph 6 rather than where it currently is.

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

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

       Clause 7, Pages 174-433                                      |

       Many  of  the  subclauses  (and  sub-subclauses)  should  be |
       rearranged  to  put them into alphabetical order.  I suggest |
       moving the headers that are currently under 7.1 out  to  the |
       top level (even though that means splitting up <float.h> and |
       <limits.h>,  neither  of  which  say  much);  alternatively, |
       <iso646.h>  (and,  perhaps,  <stdbool.h>)  would  need to be |
       moved into 7.1.  I also suggest alphabetizing the individual |
       functions within each category.                              |

       7.7, Pages 218-248                                           |

       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.1, Paragraphs 2-3, Page 229                            |

       Since  we  now  have  additional exponential functions, this |
       should be reworded parallel to 7.7.6.7 (The  exp2  function) |




       18                                            SC22/WG14 N804


       to make the base explicit.                                   |

       7.7.6.4, Paragraphs 2-3, Page 230                            |

       Since  we  now have additional log functions, this should be |
       reworded parallel to 7.7.6.10 (The log2  function)  to  make |
       the  base  explicit.   The note that the base-e logarithm is |
       the natural logarithm should  be  kept  as  a  parenthetical |
       note.

       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.   I  also  suggest a parenthetical note |
       that the base-10 logarithm is the common logarithm since  we |
       note that the base-e logarithm is the natural logarithm.

       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.15.1, Page 345                                             |

       There  doesn't  seem  to be any good reason for this being a |
       subclause; I suggest eliminating the heading.                |

       7.16.1, Page 357                                             |

       There doesn't seem to be any good reason for  this  being  a |
       subclause; I suggest eliminating the heading.                |

       7.16.3.6, Paragraph 3, Page 368                              |

       I suggest rewording the second sentence as:                  |

            In this system, weeks begin on a Monday and week 1
            of the year is the week that includes January 4th,
            which  is  also  the  week that includes the first
            Thursday of the year.

       7.16.3.6, Paragraph 5, Pages 369                             |

       I think it would be clearer if paragraph 5 were merged  into |
       the end of paragraph 2.                                      |

       7.18.1, Page 371                                             |

       There  doesn't  seem  to be any good reason for this being a |
       subclause; I suggest eliminating the heading.

       7.18.2.1, Paragraph 2, Page 372




       SC22/WG14 N804                                            19


       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;   7.18.2.2.2,   paragraph   3,  page  377;  7.18.3.2.1, |
       paragraph 3, page 379; and  7.18.3.2.2,  paragraph  3,  page |
       379.                                                         |

       7.19.1, Page 380                                             |

       There  doesn't  seem  to be any good reason for this being a |
       subclause; I suggest eliminating the heading.                |

       K.2, Page 537, Item 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, Item 12                                       |

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

       K.2, Page 538, Item 14                                       |

       I think what this is supposed to say is ``An attempt is made
       to  access  an  object  through  both  a  restrict-qualified
       pointer and another pointer not based on it.''


       4.  Suggested Possibly-substantive Changes

       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

       General                                                      |

       The  text  version  of  the  draft has not been reviewed and |
       contains numerous formatting problems such  as  superscripts |
       overprinting   information   from   the  previous  line  and |
       unintelligible expressions.                                  |

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



       20                                            SC22/WG14 N804


       Still need final words for a real  boolean  type  (N738  and |
       part  of  N743 were adopted in principle, but no final words |
       were ever produced).                                         |

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

       All of the cross references need to be checked for relevance |
       and accuracy.

       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.1, Paragraph 2, Page 33                                  |

       It has been suggested  that  a  freestanding  implementation |
       need  not  support  complex  types  since  complex  is not a |
       keyword  unless  <complex.h>  has  been   included   and   a |
       freestanding  implementation  need  not provide <complex.h>. |
       However, the actual conformance specification  in  clause  4 |
       only  exempts  freestanding  implementations  from  features |
       specified in the library clause and making complex a keyword |
       is specified here in the language clause.  We need to decide |
       what we really want to require and make  the  wording  clear |
       one way or the other.

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

       Much  of  <inttypes.h>  is  appropriate   for   freestanding |
       implementations,  but  not  all  of it.  My suggestion is to |
       move the conversion functions to  <stdlib.h>  and  <wchar.h> |
       with  the  other conversion functions, move the printf/scanf |




       SC22/WG14 N804                                            21


       macros to <stdio.h> (yes, I know that's adding  a  bunch  of |
       names  to a very popular header, but I don't like any of the |
       alternatives I've heard so far any  better),  and  move  the |
       rest  to <stdint.h> and require freestanding implementations |
       to support it.  (Changing the  name  allows  implementations |
       that  currently  support <inttypes.h> to continue to provide |
       it with the existing semantics.)                             |

       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; is it just |
       the returned value that's unspecified  or  is  the  behavior |
       completely  unspecified?   Can  such  an  implementation not |
       provide the function at all?  Can calling the function crash |
       the program?

       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?

       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.5.3, Page 283                                           |

       It has been pointed out that a call like:                    |

                 fopen("bar", "r")

       results in undefined  behavior  since  the  string  literals |
       might   not   be  distinct  and  thus  do  not  satisfy  the |
       requirements for restrict-qualified pointers.  There doesn't |
       seem  to  be  much  benefit  in making the filename and mode |
       parameters restrict-qualified, so  I  suggest  removing  the |
       qualification.  (Also freopen.)                              |

       Alternatively  (or  additionally),  we  may  want  to try to |
       revise the formal definition of restrict to  allow  aliasing |
       under  limited  circumstances (such as read-only usage), but |
       I'm afraid that's starting down the  slippery  slope  toward |
       noalias.

       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.3.1 and 7.18.2.1, Pages 185-189 and 372-377                |




       22                                            SC22/WG14 N804


       Many of these functions provide very little guidance  as  to
       their  intended  semantics, particularly with respect to the |
       additional locale-specific characters they accept.  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.                              |

       Annex I                                                      |

       There  is  a new version of ISO TR 10176; the table needs to |
       be updated (and I suggest removing the leading dashes).  The |
       new  specification  includes  extended  digits  and  special |
       characters; while it seems  reasonable  to  allow  these  in |
       identifiers,  it  seems  like  a  good  idea  to disallow an |
       extended digit as the initial character (that would allow an |
       implementation to extend the syntax for numeric constants to |
       include the extended digit characters).  I suggest  changing |
       the last sentence of 6.1.2, paragraph 2, page 34 to:         |

            The  first character must be a nondigit character;
            it  shall  not  be  a  universal  character   name
            designating a digit.

       (also in K.2).                                               |

       K.2, Page 535, Item 4                                        |

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

       K.2, Page 540, Item 10                                       |

       This isn't undefined behavior.  I think the  situation  that
       this  is  supposed  to  be describing is the one in DR #017, |
       Question 23: When a macro expansion ends with the name of  a |
       function-like  macro  and  the  first token of the remaining |
       source-file tokens is a (, and  that  macro  expansion  ends |
       with  the name of the first macro and the first token of the |
       remaining source-file tokens is again a (, it is  not  clear |
       whether  that  is  a  nested  replacement or not and thus it |
       might be  replaced  and  it  might  not.   It  is  undefined |
       behavior to depend on one or the other.                      |

       I have no idea how to express this succinctly.



       --                            Larry Jones