JTC1/SC22/WG14
N852
From peren!uunet!dkuug.dk!SC22WG14-request Mon Sep 28 13:37 PDT 1998
Return-Path: <peren!uunet!dkuug.dk!SC22WG14-request>
Received: by cobra. (5.x/SMI-SVR4)
id AA01616; Mon, 28 Sep 1998 13:37:15 -0700
id NAA27746; Mon, 28 Sep 1998 13:13:05 -0700
(peer crosschecked as: [195.215.30.66])
id QQfive04595; Mon, 28 Sep 1998 15:37:21 -0400 (EDT)
Received: from peren by cobra; Mon, 28 Sep 1998 13:37 PDT
Received: by (SMI-8.6/SMI-SVR4)
id NAA27746; Mon, 28 Sep 1998 13:13:05 -0700
(peer crosschecked as: [195.215.30.66])
id QQfive04595; Mon, 28 Sep 1998 15:37:21 -0400 (EDT)
Received: from uunet by peren; Mon, 28 Sep 1998 13:13 PDT
Received: from dkuug.dk by relay1.UU.NET with ESMTP
(peer crosschecked as: [195.215.30.66])
id QQfive04595; Mon, 28 Sep 1998 15:37:21 -0400 (EDT)
Received: (from root@localhost)
by dkuug.dk (8.8.7/8.8.7) id VAA03595
for SC22WG14-list; Mon, 28 Sep 1998 21:36:42 +0200 (CEST)
(envelope-from SC22WG14-request)
Errors-To: peren!uunet!dkuug.dk!SC22WG14-request
>Received: by (SMI-8.6/SMI-SVR4)
id NAA27746; Mon, 28 Sep 1998 13:13:05 -0700
>Received: from dkuug.dk by relay1.UU.NET with ESMTP
(peer crosschecked as: [195.215.30.66])
id QQfive04595; Mon, 28 Sep 1998 15:37:21 -0400 (EDT)
Message-Id: <199809281936.VAA03595@dkuug.dk>
Subject: (SC22WG14.6233) N852 - Editor's Report
To: uunet!dkuug.dk!SC22WG14 (WG14 mailing list),
uunet!peren.com!jb (John Benito)
Date: Mon, 28 Sep 1998 15:36:19 -0400 (EDT)
From: peren!uunet!sdrc.com!larry.jones (Larry Jones)
X-Sequence: SC22WG14@dkuug.dk 6233
Errors-To: peren!uunet!dkuug.dk!SC22WG14-request
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Content-Length: 11919
Status: R
SC22/WG14 N852
Editor's Report
September 24, 1998
1. Status
CD2 was completed and delivered to SC22 as a final CD the first week of
August along with the disposition of comments document. In addition to the
substantive changes made in response to public comments, there were also
many small editorial changes. The changes are too numerous to list here,
please see the version of CD2 with diff marks from the previous draft
(available from the committee's web site at
http://wwwold.dkuug.dk/JTC1/SC22/WG14/) for details.
The SC22 FCD ballot runs from 10 August 1998 to 8 January 1999; for
details, see http://wwwold.dkuug.dk/JTC1/SC22/open/n2794.htm. SC22
published only the PDF and text versions of the draft, but the PostScript
version is available from the committee's web site.
The US public review runs from 11 September 1998 to 10 November 1998;
details are at http://www.ncits.org/prsweb.htm. As far as I know, the US
is still willing to accept public comments from anyone, not just citizens
or residents.
2. CD2 Errata
General
Footnote 74 is missing from the text version of the draft.
There is extra whitespace following each example.
Foreword
The foreword should note that this standard is a revision of ISO/IEC
9899:1990 and includes AM1, TC1, and TC2. It should also contain a list of
major technical changes.
6.2.5 Types
Paragraph 22: ``typedomain'' should be ``type domain''.
6.3.2.3 Pointers
Paragraph 6: There needs to be special dispensation for _Bool since the
result in that case is not implementation-defined.
6.4.4.4 Character constants
Paragraph 8: UCNs are not limited to graphic characters, they may also be
used for various kinds of space characters.
2 SC22/WG14 N852
6.5.9 Equality operators
Paragraph 6: ``if'' should be ``if and only if''.
6.7.8 Initialization
Paragraph 20 doesn't take designated initializers into account. In the
first line, ``aggregate'' should be ``aggregate or union'' and the phrase
``or if the first member of a union is an aggregate or union'' should be
deleted. In the fifth line, the phrase ``the first member of the'' should
be deleted.
6.10.8 Predefined macro names
Footnote 137: ``ISO/IEC 9899:AMD1:1995'' should be ``ISO/IEC
9899/AMD1:1995''.
7.11.2.1 The localeconv function
In the example, the currency_symbol for the Netherlands should not have a
trailing space and all of the int_*_sep_by_space entries should be 0.
7.16 Boolean type and values <stdbool.h>
Paragraph 3: ``decimal constant'' should be ``integer constant''.
7.19.6.1 The fprintf function
Paragraph 6: The descriptions of the # and 0 flags should note that, for
floating-point formats, they only apply to finite values and not to
infinities or NaNs.
This also applies to 7.24.2.1 The fwprintf function.
7.23.2.6 Normalization of broken-down times
Paragraph 3: The computation of D is incorrect. The first line should be:
D = Y*365 + QUOT(Z, 400)*97 + REM(Z, 400)/4 - MOD(Z, 400)/100 +
A.2.1 Expressions
(6.5.2) postfix-expression: The last two lines have punctuation characters
in the wrong font.
Annex D Formal model of sequence points
This annex uses the term ``field'' to refer to structure and union members;
it should use the term ``member'' instead.
3. Open Issues
The index still needs more work.
SC22/WG14 N852 3
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 still some typesetting issues to be addressed, particularly in
annex F.
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.
The draft still needs some work to fully comply with Part 3 of the ISO
Directives. The major issues remaining are:
-- the formatting of tables
-- we have many subclauses that contain text in addition to subordinate
subclauses; ISO strongly discourages this
-- all references to a specific version of a standard must include the
date; it is not sufficient to include the date only in the Normative
references or the Bibliography as we currently do
-- annexes are required to appear in the order in which they are cited in
the text (and thus there has to be a citation for each annex); if
anyone has any strong feelings about ordering, please let me know
-- ISO requires numbers to be formatted with a comma for the decimal-
point character and digits before and after the decimal-point
character to be in space-separated groups of three; I believe we have
more than adequate justification for ignoring this requirement
4. My comments
5.2.4.1 Translation limits
How should a for loop be counted against the nesting level limit? It is
one iteration statement, but 6.8.5.3 says it's equivalent to a sequence of
statements that contains two blocks and a different iteration statement.
So, does it count as one, three, four, or something else?
6.2.1 Scopes of identifiers
Paragraph 3 says that label names shall be unique within a function; why
isn't this a constraint?
6.3.1.5 Real floating types
Should we add words to paragraph 2 noting that the same thing happens when
a value with excess range or precision is converted to its overt type?
4 SC22/WG14 N852
6.5.16.1 Simple assignment
Pointers can be converted to _Bool but they're not assignment compatible,
so it requires an explicit cast. Given that pointers are frequently used
in boolean contexts, I believe we should make them assignment compatible.
6.7.5.3 Function declarators (including prototypes)
Describing how an identifier in a parameter declarator that could be taken
either as a typedef name or as a parameter name is interpreted has been a
long-standing problem. C90 specified the interpretation in some specific
contexts but left the interpretation in other contexts unspecified. In
trying to better specify this for C9X, we now say that if the identifier
``can'' be treated as a typedef name, it is, but it's not clear how ``can''
is to be interpreted in this context. Consider the following fragment:
typedef int what;
int f(int (what)(int));
In the declaration of f, what ``can't'' be be treated as a typedef name
because doing so would violate the constraint that a function not return a
function. But determining that requires more than one token of look-ahead
so very few, if any, compilers actually work that way and I don't think
there's any value in requiring them to. I don't have any suggestions for
resolving this issue, it's something we need to think about.
7.1.4 Use of library functions
What, exactly, are the constraints on library macros and on macro versions
of library functions? Footnote 144 mentions that they do not have to have
the same sequence points that an actual function call would, but what about
parameter type checking and conversion? I believe that both should be
required -- both are an integral part of the interface -- but the
response to DR 107 says differently. The standard should be clarified one
way or the other.
7.4.1.8 The ispunct macro
In C89, for every character for which isprint was true, either the
character was the space character (' '), isalnum was true, or ispunct was
true. This is no longer true in C9X (for good reason, in the general
case), but it is a somewhat gratuitous change for the C locale. I believe
we should restore the C89 behavior, but just for the C locale.
7.11.2.1 The localeconv function
The description of the *_sep_by_space members of struct lconv still does
not accurately reflect the intent as illustrated by the Posix table.
Unfortunately, the table appears to be incorrect as well since there are
two entries that disagree with the implied rules. One is not particularly
important, but the other shows a serious oversight: while it is possible to
specify the formats $1.25+, $ 1.25+, $1.25 +, +1.25$, and +1.25 $, it is
not possible to specify the format + 1.25$.
SC22/WG14 N852 5
I believe the correct description of *_sep_by_space is:
0 No space separates the currency symbol and value.
1 If the currency symbol and sign string are adjacent, a space separates
them from the value; otherwise, a space separates the currency symbol
from the value.
2 If the currency symbol and sign string are adjacent, a space separates
them; otherwise, a space separates the sign string from the value.
I have come to believe the table should also be included in the standard as
an example, since it makes it easier to understand the specifications and
has been widely published (both as part of Posix and as part of the Single
Unix Specification). Based on the above, the correct table is (the two
entries which are different than Posix are highlighted):
| ||
| || p_sep_by_space
| |+------------+-------------+-------------
p_cs_precedes | p_sign_posn || 0 | 1 | 2
--------------+-------------++------------+-------------+-------------
0 | 0 || (1.25$) | (1.25 $) | > (1.25$) <
| 1 || +1.25$ | +1.25 $ | > + 1.25$ <
| 2 || 1.25$+ | 1.25 $+ | 1.25$ +
| 3 || 1.25+$ | 1.25 +$ | 1.25+ $
| 4 || 1.25$+ | 1.25 $+ | 1.25$ +
--------------+-------------++------------+-------------+-------------
1 | 0 || ($1.25) | ($ 1.25) | ($1.25)
| 1 || +$1.25 | +$ 1.25 | + $1.25
| 2 || $1.25+ | $ 1.25+ | $1.25 +
| 3 || +$1.25 | +$ 1.25 | + $1.25
| 4 || $+1.25 | $+ 1.25 | $ +1.25
Also, I question whether any of the new int_* members are necessary. While
I can certainly believe that many countries use different local and
international formats, it seems that everyone uses the same international
format. If that is true, there is no reason to parameterize it.
7.20 General utilities <stdlib.h>
Paragraph 3: There was a suggestion in UK0067 that EXIT_FAILURE and
EXIT_SUCCESS be integer constant expressions and that MB_CUR_MAX be of type
size_t. We should consider these changes.
7.20.1.3 The strtod, strtof, and strtold functions
The expected form for a hexadecimal floating-point number insists that
either a decimal point or a binary exponent part appear, but we have never
required the same for decimal floating-point. While this was presumably
done for backwards compatibility, it is not necessary as a hexadecimal
integer starting with 0X would be taken as a decimal 0 and the remaining
character would not be a valid hexadecimal integer. We should remove the
restriction.
6 SC22/WG14 N852
This also applies to 7.24.4.1.1 The wcstod, wcstof, and wcstold functions.
7.20.5 Searching and sorting utilities
Is it valid to call bsearch or qsort with nmemb equal to zero? The current
wording implies that it is not since nmemb is described as the number of
elements in an array, which cannot be zero in C.
If it is valid, is base allowed to be a null pointer in that case? I
presume not.
-- Larry Jones