JTC1/SC22/WG14
N841
Disposition of Comments Report for CD 9899, Ballot Document N2620
Document number: WG14 N841
J11/98-040
All responses are marked with a response code that corresponde with
the response codes attached, marked with "WG14:".
All responses marked E indicate Editorial and have been forwarded to
an editorial review group for their consideration.
CANADA:
Comments:
Comment #1
Category: Normative
Committee Draft subsection: 6.2.1.2
Title:
Converting to signed integral type
Description:
Section 6.2.1.2 paragraph 3 describes the result of converting a
value with integral type to a signed type which cannot represent
the value. It says that the result is implementation defined,
however, we believe that the result should be undefined, analogous
to the case where an operation yields a value which cannot
be represented by the result type (Section 6.3, paragraph 5).
WG14: Response Code: NI
-----------------------------------------------------------------
Comment #2
Category: Normative
Committee Draft subsection: 6.5.6
Title:
VLAs and typedefs
Description:
The draft needs to clearly state when typedefs involving VLAs
get evaluated. The current wording is confusing as it seems to
imply that the size is evaluated at entry to the block instead
of at the start of the scope of the typedef name.
WG14: Response Code: Y
This proposal was accepted.
-----------------------------------------------------------------
Comment #3
Category: Normative
Committee Draft subsection: 6.5.5.2
Title:
VLAs and side effects
Description:
In section 6.5.5.2, paragraph 3, the draft says, "It is
unspecified whether side effects are produced when the size
expression is evaluated". We believe that the behaviour should
be specified, either that side effects take place or that they
are disallowed and diagnosed at compile time.
WG14: Response Code: IF
-----------------------------------------------------------------
Comment #4
Category: Normative
Committee Draft subsection: 7.1.6
Title:
Width of ptrdiff_t
Description:
The width of ptrdiff_t should be required to be at least as
large as the width of size_t.
WG14: Response Code: N
A 16-bit implementation can support 64K-sized objects.
The type ptrdiff_t need not be able to store all pointer
differences, however, size_t can, as can the macros.
-----------------------------------------------------------------
Comment #5
Category: Normative
Committee Draft subsection: 6.5.4
Title:
Static objects in inline function definitions
Description:
The restriction on static objects defined within an inline
definition of a function with external linkage (section 6.5.4,
paragraph 3) is not sufficient to allow the intended
implementation strategy. Either the restriction should be
corrected (allowing the simple implementation) or dropped
(allowing an implementation to decide whether it can manage to
inline any particular function).
WG14: Response Code: M
The restriction is sufficient.
-----------------------------------------------------------------
Comment #6
Category: Normative
Committee Draft subsection: 6.5.4
Title:
Linkage of inline definitions
Description:
The interaction between inline and linkage is not clear in the
draft, and the specified syntax for creating an external
function from an inline definition is not in the spirit of C.
WG14: Response Code: CE
-----------------------------------------------------------------
Comment #7
Category: Normative
Committee Draft subsection: 7.4.3
Title:
Macros for integer constants
Description:
The macros for integer constants defined in 7.4.3 seem to be
redundant and hard to make robust. Consideration should be
given to eliminating them.
WG14: Response Code: N
-----------------------------------------------------------------
Comment #8
Category: Normative
Committee Draft subsection: 6.3.2.5
Title:
Scope of compound literals
Description:
The last paragraph of 6.3.2.5 (end of example 9, page 79) points
out a highly undesirable property of compound literals: when the
address of a compound literal is taken, correct usage is very
sensitive to the exact placement of braces.
It would seem that the utility of compound literals would not
be greatly reduced if this were simply forbidden; their primary
benefit would appear to be for the creation of compound *values*,
not anonymous variables (C already has a way to create variables,
after all). This restriction would also keep C clear of the
C++ "lifetime of temporaries" swamp.
There is already a C entity which has the desired properties: the
return value of a function. Analogous rules would suffice for
compound literals (and compound literals would fit into the
existing language better that way). Basically, 6.3.2.5 paragraph
5 needs to be modified to delete the last sentence (ie. deny
lvalue status to compound literals), and 6.3.2.5 needs to add a
constraint analogous to 6.7.1 paragraph 3 (ie. type may not be
an array, since there is nothing much that can be done with an
array which doesn't involve taking its address).
WG14: Response Code: AN
-----------------------------------------------------------------
Danish Standards Association:
7.3.2 There should only be one expected result for the
toupper() and tolower() functions, respectively.
WG14: Response Code: M
The result is required to be consistent.
-----------------------------------------------------------------
7.5.2.1 int_curr_symbol different from currency_symbol
As there may be differences between the order of how local currency is
written and how international currency is written, it is proposed to
add the following members (none of which are part of the POSIX spec, but
they are part of ISO/IEC FCD 14652) to the lconv struct, as follows:
7.5 Localization <locale.h>
[#2] ...
char int_p_cs_precedes; /* CHAR_MAX */
char int_p_sep_by_space; /* CHAR_MAX */
char int_n_cs_precedes; /* CHAR_MAX */
char int_n_sep_by_space; /* CHAR_MAX */
char int_p_sign_posn; /* CHAR_MAX */
char int_n_sign_posn; /* CHAR_MAX */
7.5.2.1 The localeconv function
[#3] ...
char int_p_cs_precedes Set to 1 or 0 if the int_curr_symbol
respectively precedes or succeeds the value for a nonnegative formatted
monetary quantity.
char int_p_sep_by_space Set to 1 or 0 if the int_curr_symbol respectively
is or is not separated by a space from the value for a nonnegative
formatted monetary quantity.
char int_n_cs_precedes Set to 1 or 0 if the int_curr_symbol respectively
precedes or succeeds the value for a negative formatted monetary
quantity.
char int_n_sep_by_space Set to 1 or 0 if the int_curr_symbol respectively
is or is not separated by a space from the value for a negative
formatted monetary quantity.
char int_p_sign_posn Set to a value indicating the positioning of the
positive_sign for a nonnegative formatted monetary quantity.
char int_n_sign_posn Set to a value indicating the positioning of the
negative_sign for a negative formatted monetary quantity.
In section 7.5.2.1 the examples need to be enhanced.
There cannot be a point after ITL.
Netherlands use a kind of small "f".
Norway have at least a space between "kr" and the value.
We need examples with all the new variables, int_p_cs_precedes etc.
This is all done in the text below.
WG14: Response Code: Y
The Committee adopted WG14 N821, this proposal incorporates
the desired features.
-----------------------------------------------------------------
7.5.2.1 The localeconv function
Examples
[#8] The following table illustrates the rules which may well be used
by
five countries to format monetary quantities.
Country Positive format Negative format International format
Italy L.1.234 -L.1.234 ITL 1.234
Netherlands f 1.234,56 f -1.234,56 NLG 1.234,56
Norway kr 1.234,56 kr 1.234,56- NOK 1.234,56
Switzerland SFrs.1,234.56 SFrs.1,234.56C CHF 1,234.56
Finland 1.234,56 mk -1.234,56 mk FIM 1.234,56
[#9] For these five countries, the respective values for the monetary
members of the structure returned by localeconv are:
Italy Netherlands Norway Switzerland Finland
int_curr_symbol "ITL " "NLG " "NOK " "CHF " "FIM "
currency_symbol "L." "f" "kr" "SFrs." "mk"
mon_decimal_point "" "," "," "." ","
mon_thousands_sep "." "." "." "," "."
mon_grouping "\3" "\3" "\3" "\3" "\3"
positive_sign "" "" "" "" ""
negative_sign "-" "-" "-" "C" "-"
int_frac_digits 0 2 2 2 2
frac_digits 0 2 2 2 2
p_cs_precedes 1 1 1 1 0
p_sep_by_space 0 1 0 0 1
n_cs_precedes 1 1 1 1 0
n_sep_by_space 0 1 0 0 1
p_sign_posn 1 1 1 1 1
n_sign_posn 1 4 2 2 1
int_p_cs_precedes 1 1 1 1 1
int_p_sep_by_space 0 1 0 0 1
int_n_cs_precedes 1 1 1 1 1
int_n_sep_by_space 0 1 0 0 1
int_p_sign_posn 1 1 1 1 1
int_n_sign_posn 1 4 2 2 4
WG14: Response Code: Y
The Committee adopted WG14 N821, this proposal incorporates
the desired features.
-----------------------------------------------------------------
7.4.2.1 p_sep_by_space and n_sep_by_space
POSIX has added a third possibility for a formatted monetary quantity,
so now we have:
No space separates the currency_symbol from the value.
A space separates the symbol from the value.
*New* A space separates the symbol and the value, if these entities are
next to eachother.
The new parameter is required to properly display monetary amounts
in Denmark and a number of other European countries. For example the
format "DKK -1.234,56" is very common and not doable with the current
C standard.
WG14: Response Code: Y
The Committee adopted WG14 N821, this proposal incorporates
the desired features.
-----------------------------------------------------------------
7.5.2.1 The localeconv function
[#3] ...
char p_sep_by_space Set to 0 if no space separates the currency_symbol
from the value for a nonnegative formatted monetary quantity; set to 1 if
a space separates the symbol from the value; and set to 2 if a space
separates the symbol and the value, if adjacent.
char n_sep_by_space Set to 0 if no space separates the currency_symbol
from the value for a negative formatted monetary quantity; set to 1 if a
space separates the symbol from the value; and set to 2 if a space
separates the symbol and the value, if adjacent.
char int_p_sep_by_space Set to 0 if no space separates the int_curr_symbol
from the value for a nonnegative formatted monetary quantity; set to 1 if
a space separates the symbol from the value; and set to 2 if a space
separates the symbol and the value, if adjacent.
char int_n_sep_by_space Set to 0 if no space separates the int_curr_symbol
from the value for a negative formatted monetary quantity; set to 1 if a
space separates the symbol from the value; and set to 2 if a space
separates the symbol and the value, if adjacent.
This section should go into the rationale
A table giving example formats for the combinations of p_cs_precedes,
p_sign_posn and p_sep_by_space is given below, given that the
positive_sign is "+" and the currency_symbol is "$".
p_sep_by_space
2 1 0
p_cs_precedes = 1 p_sign_posn = 0 ($ 1.25) ($ 1.25) ($1.25)
p_sign_posn = 1 + $1.25 +$ 1.25 +$1.25
p_sign_posn = 2 $1.25 + $ 1.25+ $1.25+
p_sign_posn = 3 + $1.25 +$ 1.25 +$1.25
p_sign_posn = 4 $ +1.25 $+ 1.25 $+1.25
p_cs_precedes = 0 p_sign_posn = 0 (1.25 $) (1.25 $) (1.25$)
p_sign_posn = 1 +1.25 $ +1.25 $ +1.25$
p_sign_posn = 2 1.25$ + 1.25 $+ 1.25$+
p_sign_posn = 3 1.25+ $ 1.25 +$ 1.25+$
p_sign_posn = 4 1.25$ + 1.25 $+ 1.25$+
------------------------------------------------------------------
WG14: Response Code: Y
The Committee adopted WG14 N821, this proposal incorporates
the desired features.
-----------------------------------------------------------------
7.14.3.5 strftime
The date utility in POSIX-2 4.15 and the strftime() function from
the Open Group Single Unix Specification has all of the formats
of C's strftime() plus more, all of which are proposed to be added to
strftime(), ie merged with the current list:
%C is replaced by the year divided by 100 and truncated to an
integer, as a decimal number (00-99)
%D is replaced by the date in the format mm/dd/yy
%e is replaced by the day of the month as a decimal number (1-31
in a two-digit field with leading <space> fill)
%h a synonym for %b
%n is replaced by a <newline> character
%r is replaced by the 12 h clock time (01-12) using the AM/PM
notation; in the "C" locale, this shall be equivalent to
"%I:%M:%S %p"
%R is replaced by the time in 24 hour notation (%H:%M)
%t is replaced by a <tab> character
A number of modified field descriptors %O<d> and %E<d> are also
defined in POSIX.2 (4.15.4.2) or in The Open Group's strftime()
definition. Text to be added for the C standard,
after the "%%" definition:
Some field descriptors can be modified by the E and O modifier
characters to indicate a different format or specification as
specified in the LC_TIME locale description. If the corresponding
data (see era, era_year, era_d_fmt, and alt_digits) is not specified
or not supported for the current locale, the unmodified field
descriptor value shall be used.
%Ec Locale's alternate date and time representation.
%EC The name of the base year (period) in the locale's alternate
representation.
%Ex Locale's alternate date representation.
%EX Locale's alternate time representation.
%Ey Offset from %EC (year only) in the locale's alternate
representation.
%EY Full alternate year representation.
%Od Day of month using the locale's alternate numeric symbols.
%Oe Day of month using the locale's alternate numeric symbols.
%OH Hour (24-hour clock) using the locale's alternate numeric
symbols.
%OI Hour (12-hour clock) using the locale's alternate numeric
symbols.
%Om Month using the locale's alternate numeric symbols.
%OM Minutes using the locale's alternate numeric symbols.
%OS Seconds using the locale's alternate numeric symbols.
%Ou Weekday using the locale's alternate numeric symbols (Monday=1).
%OU Week number of the year (Sunday as the first day of the week)
using the locale's alternate numeric symbols.
%OV Week number using the locale's alternate numeric symbols, using
rules corresponding to %V.
%Ow Weekday as number in the locale's alternate representation
(Sunday=0).
%OW Week number of the year (Monday as the first day of the week)
using the locale's alternate numeric symbols.
%Oy Year (offset from %C) in alternate representation.
--------------------------------------------------
WG14: Response Code: Y
The Committee adopted WG14 N821, this proposal incorporates
the desired features.
-----------------------------------------------------------------
Basic addressing of I/O hardware support should be included
in C9X, as I/O addressing support in C is of major importance for
the market for free-standing environments.
Denmark believe that having support for I/O addressing in C will be
a great benefit for both the individual programmer, the individual
company, and the electronic industry as a whole.
By adding I/O addressing support in C9x as an optional annex, as proposed
in N731, the requirements from the market for free-standing environments
can be fulfilled, without any inconvenience for those compilers for hosted
environments which do not want to support I/O addressing.
WG14: Response Code: N
There was insufficient interest by committee members to
make this change. This issue has been debated since 1995.
The Committee feels that there is insufficient technical
expertise within the working group, and there are efforts
outside this working group that are attempting to standardize
like features.
-----------------------------------------------------------------
FRANCE
General comments:
1. Committee Draft subsections: many
Category: Feature that should be removed (major technical)
Title: Suppression of long long
Rationale:
In C90, the long type had two uses:
- it was the longest integer type available (then by example
its use at the preprocessor level),
- it was the only integer type which warranted 32 bits.
It also had the historical characteristics to be somewhat less
slowly than type int, and to be used to represent offsets in
files (classicaly the integral measure with the greatest
magnitude).
C9X try to extend the standard to permit the writing of programs
handling 64 bits quantities; therefore, this will destroy (at
least) one of the above assertions.
Experience shows that in these cases, one should not extrapolate
from existing features, but rather create a new, heathly mechanism.
This had be done in C9X, and the result is the subclause 7.4 (the
<inttypes.h> header). This clearly distinguish integer types
having a known width from the types named [u]intmax_t, which are
accompanied by functions strtoimax, strtoumax, wcstoimax and
wcstoumax.
Unfortunately, the support for these types, and in particular
[u]intmax_t, is scarse in the rest of the library.
Instead, the proposed draft introduces a solution which have been
implanted in a part of the market: aside from long, there is a new
integer type, long long, which is warrantied to be (at least)
64 bits long; and a number of new library functions to help dealing
with this new type (atoll, llabs, lldiv, llrint, llround, strtoll,
strtoull, wcstoll, wcstoull), and a new "ll" modifier to integer
convertions with *printf and *scanf.
<inttypes.h> correctly does the difference between the (at least)
64 buts long type and the longest type. long long and the
proposed library functions do not, therefore the problem set up
by long (2 signifiances) will not be solved by long long. In fact,
it will lead programers to think long "is" 32 bits and long long
"is" 64 bits... therefore making the very point of <inttypes.h>
useless.
Another defect is that while the historical need for "big" integer
types is with file offsets, there is no long long equivalents for
fseek and ftell. These functions, while superseeded by fsetpos
and fgetpos in some uses, are still necessary (for example when
the program calculate itself the offsets, or when the file have
an externaly defined structure with internal "pointers").
Recommanded changes:
From this analysis, we feel that:
a) long long should be suppressed in the standard, but the door
should be left opened for its use by the mean of the extended
integer types in 6.1.2.5 (note 25 should be modified);
b) direct and indirect obligations to the types described by the
standard should be extended to all the extended integer types
(this include lrint in 7.8, Annex F, and the modification below
to subclause 7.4.4, point #18);
c) [u]intmax_t should be always used when referencing the
longest type (as it is already done in 6.8.2);
d) new functions should be added to <inttypes.h> to do the
equivalent of maxabs, maxdiv, fseekmax, ftellmax, maxrint and
maxround (names are just indications).
Side points:
e) adding atoimax is more problematic, as the atol function is
supposed to be superseeded by strtol.
f) modifier "L" (or "m") could be used to handling integers
of type [u]intmax_t with *printf and *scanf: this is not
necessarily a good idea, as it would also need a modifier
for size_t...)
WG14: Response Code: PR
-----------------------------------------------------------------
2. Committee Draft subsections: 5.1.1.2, 5.2.1
Category: Request for information/clarification (major question)
Title: Clarification of the status of UCN
Rationale:
5.1.1.2p1, item 1, and 5.2.1p5 does not make clear if the notation
\Unnnnnnnn consist of either 10 or 1 source character(s). Note 6
in 5.1.1.2 seems to imply it is only 1 character; however notes are
not normative.
If UCN are 10 characters long, there are a number of latent problems
in 5.1.2, 6.1.3.4, 6.1.4, 6.1.7, 6.8.3.2, etc., most of them related
with the special status of the \ character.
We shall assume the correct reading is 1 character.
We shall also assume that UCNs are full-right members of the character
sets (they may need to be clarified in 5.2.1).
There is also a change to be done in 5.1.1.2 to make this clear
(see below, point #4).
Also, a lot of place have not been updated with the appearance of UCNs.
They should be rewritten accordingly (see below for details).
WG14: Response Code: DA
The committee chose a different approach, see WG14 N837
UCN handling.
-----------------------------------------------------------------
Specific comments:
1. Committee Draft subsections: 4, 7.1, 7.4
Category: Normative change to intent of existing feature (minor
technical)
Title: Making <inttypes.h> available to freestanding implementations
Rationale:
Most of the content of subclause 7.4 (i.e. excluding 7.4.4 and 7.4.6)
should be available for freestanding implementations.
In fact, as those implementations are usualy "closer to the metal",
they may more benefit from these changes like precisely-sized
types than the hosted ones.
However, the whole content of actual subclause 7.4 is not suitable
for freestanding implementations.
Proposed solution:
A way to achieve it is to divide subclause 7.4 into two parts: a
first one, containing the actuals subclauses 7.4 to 7.4.3 and
7.4.5, should be put in a new subclause 7.1.x preceding 7.1.6,
and should be made mandatory to freestanding implementations
(by updating clause 4). It should keep the existing title.
The rest, i.e. 7.4.4 and 7.4.6, should be left as an independant
subclause 7.x (while being moved, depending of the spelling of
the corresponding header); it may be named <stdint.h> (just a
proposal).
For strtoimax() and the like to be usefully used, it might be
necessary to make the declaration of intmax_t also available
in this new header.
WG14: Response Code: AD
-----------------------------------------------------------------
2. Committee Draft subsection: 5.1.1.2
Category: Request for information/clarification (minor question)
Title: locale to be used for source characters
What is the locale to be used for the convertion of multi-byte
source characters to UCN and then to execution characters?
Should it be unspecified or implementation-defined?
Or locale-specific (to permit strict conformance)?
A reference in annexe K is also needed.
Rationale:
As it stands now, it is undefined for source characters, thus
forbids any strictly conforming program with characters outer of
the basic character set should be written with \u or \U. Is it
as intended?
WG14: Response Code: DA
See WG14 N837 UCN handling.
-----------------------------------------------------------------
3. Committee Draft subsection: 5.1.1.2
Category: Normative change to existing feature retaining the
original intent (minor technical)
Title: Prohibit surrogates to being used as UCNs
Rationale:
5.1.1.2p2 (Contraints) excludes some ranges to be used with UCNs.
The range D000-DFFF (used for UTF-16, these values by themselves, named
"surrogates", do not represent characters) should be excluded as well.
Proposed solution:
Exclude the range D000-DFFF as well.
WG14: Response Code: Y
-----------------------------------------------------------------
3. Committee Draft subsection: 5.1.1.2
Category: Editorial change/non-normative contribution (minor editorial)
Title: Consistency with ISO/IEC 10646
Proposed change:
5.1.1.2p2 (Contraints) specifies some range to be not used with UCNs.
The references should be written in full (canonical) form, like 0000 0000,
0000 0020, 0000 007F, 0000 009F (and 0000 D000, 0000 DFFF).
WG14: Response Code: Y
-----------------------------------------------------------------
4. Committee Draft subsections: 5.1.1.2
Category: Normative change to intent of existing feature (major
technical)
Title: Clarification of the status of UCN
Rationale:
5.1.1.2p1, item 1, and 5.2.1p5 does not make clear if the notation
\Unnnnnnnn consist of either 10 or 1 source character(s). Note 6
in 5.1.1.2 seems to imply it is only 1 character; however notes are
not normative.
Proposed solution:
If "1 character" is the correct reading, then a sentence should be
added to 5.1.1.2 to specify that the sequence of 10 source characters
{\}{U}{n}{n}{n}{n}{n}{n}{n}{n} should be transformed in one character
(during translation phase 1).
WG14: Response Code: DA
See WG14 N837 UCN handling.
-----------------------------------------------------------------
5. Committee Draft subsection: 5.2.1
Category: Editorial change/non-normative contribution (minor editorial)
Title: Consistency with ISO/IEC 10646
Proposed change:
In 5.2.1p5, the reference to the Standard should be ISO/IEC 10646,
without specifying the 1st part. This way, one could safely uses
characters outside BMP when they will be defined.
WG14: Response Code: Y
-----------------------------------------------------------------
6. Committee Draft subsection: 5.2.1
Category: Inconsistency (minor technical)
Title: Are UCN part of the basic character set?
Rationale:
5.2.1p1, last sentence should written another way. As it stands now,
any additional
members beyond those required by this subclause are locale-
specific.
Given the fact that the UCN notation is described in this very
subclause, and that it includes all the characters in ISO/IEC 10646,
the present writing is somewhat useless. See also below an
implication for 6.8p4.
Proposed change:
Move the UCNs (5.1.2p4-5) to another (new) subclause to highlight the
difference between the basic and the extended character sets.
WG14: Response Code: DA
See WG14 N837 UCN handling.
-----------------------------------------------------------------
7. Committee Draft subsection: 5.2.1
Category: Inconsistency (minor editorial)
Title: Clarification of the status of UCN
Proposed change:
In 5.2.1p3, the last sentence should be deleted. It says:
If any other characters are
encountered in a source file (except in a character
constant, a string literal, a header name, a comment, or a
preprocessing token that is never converted to a token), the
behavior is undefined.
Another possibility is to add identifer to the list of items.
WG14: Response Code: AL
See WG14 N837 UCN handling.
-----------------------------------------------------------------
8. Committee Draft subsection: 5.2.1.1
Category: Editorial change/non-normative contribution (minor editorial)
Title: Correct designation of a national standard
Rationale:
5.2.1.1, note 12, references "the ASCII code set". In the context of
an International Standard, it should be for example "the US ASCII code
set".
Proposed change:
Add "US".
WG14: Response Code: EY
-----------------------------------------------------------------
9. Committee Draft subsection: 5.2.1.2
Category: Inconsistency (minor editorial)
Title: Handling of UCNs into identifiers
Rationale:
In 5.2.1.2p2, in the two first items, "identifier" should be added to
the lists.
They also may be considered now useless, as shift states have been
removed in translation phase 1, and hence all multibyte characters
are valid (or the source will be rejected at translation phase 1).
Proposed changes:
- An identifier, comment, string literal, character constant,
or header name shall begin and end in the initial shift
state.
- An identifier, comment, string literal, character constant,
or header name shall consist of a sequence of valid
multibyte characters.
WG14: Response Code: AL
See WG14 N837 UCN handling.
-----------------------------------------------------------------
10. Committee Draft subsection: 5.2.2
Category: Normative change to existing feature retaining the original
intent (minor technical)
Title: Making character display semantics in line with MSE
Rationale:
5.2.2p1, first sentence, describes the `active position' in relation
with fputc:
[#1] The active position is that location on a display
device where the next character output by the fputc function
would appear.
It should be `the fputc or fputwc functions' instead.
Similarly, the next sentence describes a `printable character' as being
defined by isprint:
The intent of writing a printable character
(as defined by the isprint function) to a display device [...]
It should be `as defined by the isprint or iswprint functions' instead.
WG14: Response Code: EY
-----------------------------------------------------------------
11. Committee Draft subsections: 6.1.3.4, 6.1.4
Category: Inconsistency (minor technical)
Title: Making string litterals in line with character constants
Rationale:
The rules for the building of wide character constants and
string literals are non consistent.
6.1.3.4p11 says, in part:
The value of a wide
character constant containing a single multibyte character
that maps to a member of the extended execution character
set is the wide character (code) corresponding to that
multibyte character, as defined by the mbtowc function, with
an implementation-defined current locale. The value of a
wide character constant containing more than one multibyte
character, or containing a multibyte character or escape
sequence not represented in the extended execution character
set, is implementation-defined.
On the other hand, 6.1.4p5 says:
for
wide string literals, the array elements have type wchar_t,
and are initialized with the sequence of wide characters
corresponding to the multibyte character sequence.
Proposed solution:
The latter should be reworded to the following:
for
wide string literals, the array elements have type wchar_t,
and are initialized with the sequence of wide characters
corresponding to the multibyte character sequence, as
defined by the mbstowcs function, with an implementation-
defined current locale. The value of a wide string literal
containing multibyte characters or escape sequences not
represented in the extended execution character set, is
implementation-defined.
Also note that if a change is done to 6.1.3.4p11 to include
universal character names in the list of items that may lead to
implementation-defined behavior, the same change should be made
to the proposed text accordingly.
WG14: Response Code: E
-----------------------------------------------------------------
12. Committee Draft subsection: 6.1.7
Category: Inconsistency (minor editorial)
Title: Handling of UCNs into an example
Proposed change:
6.1.7p4, last example, should be
{#}{define} {const}{.}{member}{\U00000040}{\U00000024}
WG14: Response Code: DA
See WG14 N837 UCN handling.
-----------------------------------------------------------------
13. Committee Draft subsection: 6.1.9
Category: Inconsistency (minor editorial)
Title: Handling of multibytes during preprocessing
Rationale:
6.1.9p2, last sentence.
There should be no need to examine the comments to find multibytes
characters, as they are replaced by UCN during translation phase 1.
Proposed solution:
Remove the reference to multibytes.
WG14: Response Code: DA
See WG14 N837 UCN handling.
-----------------------------------------------------------------
14. Committee Draft subsection: 6.8
Category: Inconsistency (minor editorial)
Title: Are UCN source characters? or escape sequences? or another thing?
Proposed change:
6.8p4, replace
[#4] In the definition of an object-like macro, if the first
character of a replacement list is not a character required
by subclause 5.2.1, then there shall be white-space
separation between the identifier and the replacement
list.122
with
In the definition of an object-like macro, if the first
character of a replacement list is neither a character
required by subclause 5.2.1, nor an universal character name
listed in Annex I, then there shall be white-space separation
between the identifier and the replacement list.{122}
The footnote then remains valid.
Also note that the above modification (#6) must be made, as presently
all UCNs are required by subclause 5.2.1
WG14: Response Code: DA
See WG14 N837 UCN handling.
-----------------------------------------------------------------
15. Committee Draft subsection: 6.8.3.3
Category: Inconsistency (minor editorial)
Title: Are UCN source characters? or escape sequences? or another thing?
Proposed change:
6.8.3.3p3, add before last sentence
If the result of the concatenation is syntaxly identical to an
UCN, the behavior is undefined.
This will prevent the following example to be strictly conforming:
#define paste(a,b) a ## b
#define mkstr1(s) #s
#define mkstr(s) mkstr1(s)
char value[] = mkstr(paste(\u, 0024));
as it will fool a number of implementations using preprocessors.
WG14: Response Code: DA
See WG14 N837 UCN handling.
-----------------------------------------------------------------
16. Committee Draft subsection: 6.8.8
Category: Other: Addition of a new feature (minor technical)
Title: New conditionaly predefined macro name __STDC_ISO_10646__
Rationale:
While C9X adds support for all the universal character names in
identifiers, there is currently no requisite to an implementation
for the extended set of character to represent the whole set
defined in ISO/IEC 10646:1993, and furthermore no conforming way
for a program to learn if the type wchar_t could be used for
this purpose. This point intends to solve this problem.
Proposed solution:
By defining a new constant named __STDC_ISO_10646__, the
implementation will indicate that the values of type wchar_t are
suitable to represent the elements of the universal character
set defined in ISO/IEC 10646; as an example, in this case,
L'A' will be guaranteed to be equal to 0x0041u.
Furthermore, as ISO/IEC 10646 is an evolving standard, the value
of the predefined macro should reflect the level ISO/IEC
implemented, by the same mechanism as used by __STDC_VERSION__,
i.e. by specifiying the year and month of the registration of
the lastly supported amendment (so support of ISO/IEC 10646:1993
up to Am.9, which is the last one issued now, will be showed by
defining the macro as 199712L).
This can be done by adding a new item to the list in 6.8.8p2,
which reads as:
__STDC_ISO_10646__ A decimal constant of the form YyyyMmL
(for example 199712L), intended to indicate that the values
of the type wchar_t (as defined in the <stddef.h> header)
are the coded representations of the characters defined
by ISO/IEC 10646 (Universal Multiple-Octet Coded Character
Set, UCS), to the level specified by this standard with
all amendments applied up to the month "Mm" of the year
"Yyyy".
A better wording can perhaps being found.
Another solution (similar to the one used for floating-point
support) is to include a new normative annex, and to require
in this annex the specifications of Unicode (regarding
classification of characters) and of ISO/IEC FCD 14652
(regarding collation of strings made of UCS characters).
WG14: Response Code: Y
-----------------------------------------------------------------
17. Committee Draft subsection: 7.1, 7.17
Category: Editorial change/non-normative contribution (minor editorial)
Title: Moving <iso646.h> to a more logicial position
Rationale:
7.17, Alternative spellings <iso646.h>, is nowadays positionned
after its established position coming from Am.1:1996 to
ISO/IEC 9899:1990, i.e. after the <time.h> subclause.
This is now illogical, as <stdbool.h> (also required for
freestanding implementations) have been put in subclause 7.1,
and as the new header introduced by C9X have been put in
their logical position regarding the alphabetic order (which
is not the case for <iso646.h>).
Proposed solution:
Subclause 7.17 should be moved to a new subclause 7.1.x
before 7.1.6 <stddef.h>.
WG14: Response Code: AD
-----------------------------------------------------------------
18. Committee Draft subsection: 7.4.4
Category: Inconsistency (minor technical)
Title: Allow other convertions modifiers to be used in 7.4.4
Rationale:
6.1.2.5 introduces the new concept of "extended integer types", which
can exist beyond char, short, int, long and long long.
Unfortunately, 7.4 specifies that modifiers corresponding to the
defined types should be those described by the standard ("hh", "h",
"l" and "ll") therefore forbiding a implementation to define
the types in <inttypes.h> as one of the extented types.
Proposed solution:
Remove the restriction.
WG14: Response Code: M
7.4 does not prohibit using implementation-specific modifiers.
-----------------------------------------------------------------
19. Committee Draft subsection: 7.19.7.1.2
Category: Inconsistency (minor technical)
Title: Making positive the non-error return value of wctob
Rationale:
7.19.7.1.2, the wctob function, does not describe the sign convention of
the single-byte representation returned. In particular, 7.19.7.1.2p3
says:
Otherwise, it returns the single-byte representation
of that character.
Proposed solution:
It should be written as
Otherwise, it returns the single-byte representation
of that character, as an unsigned char converted to an int.
(This is copied from the description of fgetc).
Note this is a quiet change from ISO/IEC 9899:1990/Am.1:1996
(existing implementations where char are signed may have
chosen to return negative values; the new behavior can lead
to overflow problems).
WG14: Response Code: EY
-----------------------------------------------------------------
JAPAN
1. Technical Comments
---------------------
Japan has been having some technical comments which were
submitted to SC22 at the CD registration ballot. WG14 made
the disposion paper (SC22 N2618) for these comments.
However, Japan can not agree with some of WG14's
dispositions. Section 3 in this paper describes such a
kind of open issues (including editorial comments). As for
technical issues, please refere subsection 3.1 through 3.3:
- 3.1 The 64 bit data type should be optional
- 3.2 The function atoll() is redundant as the ISO C
language standard
- 3.3 Example of ## operator
1.1 Multibyte characters in source file
@ Subclause "5.1.1.2 Translation phases"
Page 8-9, line 4-6 in paragraph 1:
> Any multibyte source file character not in the basic
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> source character set is replaced by the
> ~~~~~~~~~~~~~~~~~~~~
> universal-character-name that designates that multibyte
> character.
This description reads that *ALL* of conforming
implementations should replace *ANY* MULTIBYTE CHARACTERS IN
THE SOURCE FILE to universal-character-name. If this is
true, we have three questions below:
1) This rule says that any Japanese Kanji Characters in the
source file should be replaced to universal-character-name
by *ANY* implementations EVEN IF THEY ARE MADE IN US. Is
this the intention of SC22/WG14? (We do not think so.)
2) Does the ISO C standard prohibit an implementation from
supporting multibyte character as the source character
set which are NOT defined in the Annex I "Universal
character names for identifiers"? (We do not think
this is SC22/WG14's intention.)
3) This rule says that *ALL* of conforming implementations must
have the conversion table between physical multibyte
characters and a full set of universal-character-name
defined in Annex I. The table must be very big. That is,
the conforming implementation must be very fat. It is
not welcome to users. Is this the intention of
SC22/WG14? (We do not think so.)
So, the above description should be changed to more
precise sentence by using well-defined terms:
> Then, the member of the extended character set of the
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> source which is not in the basic source character set may
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> be replaced by the universal-character-name that
> designates that extended source character set members.
WG14: Response Code: SD
See WG14 N837 UCN handling.
-----------------------------------------------------------------
2. Editorial Comments
---------------------
2.1 Multibyte characters in source file
@ Subclause "5.1.1.2 Translation phases"
Page 8, Line 3-5 in paragraph 1:
> 1. Physical source file multibyte characters are mapped to
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the source character set ... if necessary.
> Any multibyte source file character not in the basic
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> source character set is...
Wording "Physical source file multibyte characters" and
"multibyte source file character" are slightly
unintelligible.
> Any source file multibyte character not in the basic
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> source character ...
makes clearer.
WG14: Response Code: SD
See WG14 N837 UCN handling.
-----------------------------------------------------------------
2.2 Wrong reference to Annex I
@ Subclause "6.1.2 Identifier"
Page 34, line 4 in paragraph 2:
"Annex H" should be corrcted to "Annex I".
WG14: Response Code: EY
-----------------------------------------------------------------
2.3 "Function-sepcifiers" should be "function-specifier"
@ Subclause "6.5 Declarations"
Page 100, line 7 in paragraph 1:
Syntactic category "function-sepcifiers" should be the same
as "function-specifier" which is defined in "6.5.4 Function
specifiers" (Page 116). Threfore, "function-sepcifiers"
should be changed to "function-specifier". Annex B2.2 (page
444) should be corrected similarly.
WG14: Response Code: EY
-----------------------------------------------------------------
2.4 "Function-sepcifiers" should be followed by other
syntactic category
@ Subclause "6.5 Declarations"
Page 100, line 7 in paragraph 1:
Syntactic category "function-sepcifiers" is defined
alone. So, the C user cannot write other
"declaration-specifiers" following it. It should be
followed by "declaration-specifiers opt". Annex B2.2 (page
444) should be corrected similarly.
WG14: Response Code: EY
-----------------------------------------------------------------
2.5 Wrong sentence in Tags
@ Subclause "6.5.2.3 Tags"
Page 108, line 2 in paragraph 3:
"The type is complete" should be corrcted to
"The type is incomplete".
WG14: Response Code: EY
-----------------------------------------------------------------
2.6 The behavior of "rewrite" should be clarified.
@ Subclause "6.5.5.3 Function declarators(including
prototypes)"
Page 123, line 1 in paragraph 4:
The term "rewrite" in the description:
"After all rewrites, the parameters in a parameter-type-list
that is part of a function definition shall not have
incomplete type."
is not defined anywhere. The behavior of "rewrite" should
be clarified.
WG14: Response Code: AL
-----------------------------------------------------------------
2.7 Examples for VLA is needed
@ Subclause "6.5.6 Type names"
Page 127, paragraph 3:
The definitions of variable length array (VLA) are added in
the syntax of the subclause 6.5.6. But any examples of VLA
does not exist. Threfore, the examples of VLA should be
added if possible like subclause 6.5.5.2 and 6.5.5.3.
WG14: Response Code: EY
-----------------------------------------------------------------
2.8 "Declaration-list" should be defined
@ Subclause "6.7.1 Function definitions"
Page 150, line 2 in paragraph 1:
In draft 11, "declaration-list" was dropped, because
"block-item-list" was newly defined in "6.6.2 Compound
statement, or block" (page 140) instead of "declaration-list"
and "statement-list". It should be defined in 6.7.1 or
elsewhere. Annex B2.4 (page 448) should be corrected
similarly.
WG14: Response Code: EY
-----------------------------------------------------------------
2.9 Publised year of ISO/IEC 9899 mismatches
@ Subclause "6.8.8 Predefined macro names"
Page 171, footnote 128
> 128. The value in ISO/IEC 9899:1994 was 199409L.
@ Annex A "Bibliography" 12.
Page 434
> ISO/IEC 9899:1993, Programming languages -- C
Which is correct?
Please use the correct document name/year.
WG14: Response Code: EY
-----------------------------------------------------------------
2.10 Garbage in postscript file
@ Subclause "6.8.8 Predefined macro names"
Pages 171, line 2 in paragraph 2:
> 1912.nr:c 0u+000m'unu
This line looks like an garbage in the post script file of
CD.
Please correct it.
WG14: Response Code: EY
-----------------------------------------------------------------
2.11 Missing information from asert macro for the identifire
__func__
@ Subclause "7.2.1.1 The assert macro"
Page 183, line 3-6 in paragraph 2:
The information about the identifire __func__ should be
added to the contents of the information written by asert
macro.
WG14: Response Code: EY
-----------------------------------------------------------------
2.12 Unnecessary description of C++ implementations
@ Subclause "7.4.2 Limits of specified-width integer types"
Page 193, footnote 149:
@ Subclause "7.4.3 Macros for integer constants"
Page 195, footnote 150:
@ Subclause "7.4.4 Macros for format specifiers"
Page 196. footnote 151:
What is the intention of using the term "C++ implementations"
in the footnote 149, 150, and 151 ?
They should be removed from the specification of the C
standard.
WG14: Response Code: EN
Maintaining compatibility between C and C++ is a goal
of both WG14 and WG21. We believe that this sort of
guidance is very useful.
-----------------------------------------------------------------
2.13 Place of reference to the footnote 153
@ Subclause "7.5 Localization <locale.h>"
Page 202, line 1 in paragraph 3:
It seems that the place of the reference to the footnote 153
is wrong (but, Japan is not so convinced whether or not it is
wrong.)
> The macros defined are NULL (described in 7.1.6);
> and 153
+--+-> Is this place right?
Please make clear.
WG14: Response Code: EY
-----------------------------------------------------------------
2.14 Defintions for float and long double math functions
@ Subclause "7.7 Mathematics <math.h>"
Page 218, paragraph 1:
@ Subclause "7.7.11.3 The nextafter function"
Page 242
@ Subclause "7.7.11.4 The nextafterx function"
Page 243, paragraph 2:
In subclause 7.7, only "double" version mathematics
functions are defined, and a definition of its "float"
and "long double" version is derived by applying the rule
described below:
there are functions with the same name but with f
and l suffixes which are corresponding functions
with float and long double arguments and return
values.
But, every declaration for the "float" and "long double"
version should be explicitly written in subclause 7.7,
because the definition of some functions which have multiple
arguments can not be derived according to the above rule.
One expample is shown below.
The "nextafer" function has two double parameters.
double nextafter(double, double);
But the type of second parameter of its "float" and "long
double" versions, "nextaferf" and "nextaferl", are
ambigious.
According to the definition of "float" and "long double"
versions, second parameter may have type "float" and "long
double" respectively, such as in Annex D.9(page 465).
float nextafterf(float, float);
long double nextafterl(long double, long double);
On the other hand, the "nextafterx" function is defined as
follows
The nextaferx function is equaivalent to the nextafrer
function except that the second parameter has type long
double.
In this case, the type of second parameter has only type
"long double".
According to this definition, type of second parameter
of the "nextafter" function may have only the type "double".
float nextafterf(float, double);
long double nextafterl(long double, double);
Which declarations of nextafter are correct? It is ambigious.
WG14: Response Code: AD
Explicit prototypes are now present in the Draft.
-----------------------------------------------------------------
2.15 Necessary rationale for the changes of some
environmental limits
@ Subclause "7.13.6.1 The fprintf function" Environmental limit
Page 293, line 2 in paragraph 14:
The minimum value for the maximum number of characters
produced by any single conversion is changed from 509 (in
the current ISO/IEC 9899) to 4095. And also, some of other
environmental limits are changed from ISO/IEC 9899. Please
describe a clear rationale for these changes.
WG14: Response Code: ER
-----------------------------------------------------------------
2.16 Wrong notation in the example of fprintf/fscanf for
multibyte characters
1)
@ Subclause "7.13.6.1 The fprintf fumction" Examples
Page 294, line3 in paragraph 16:
@ Subclause "7.13.6.2 The fscanf functin" Examples 1,2,3,4
Page 302, line 3 in paragraph 18:
Two character (or, two byte) notation "$0" is used to
represent the first byte of a multibyte character. However,
in the original Amendment 1, a *single* square mark is used
for this purpose in order to clearly represen that it is
just *one* byte.
Please use one byte notation to represent the first byte of
a multibyte character.
2)
@ Page 294, paragraph 19:
The printed image of the example of fprintf is NOT correct
because the two byte notation $0 is used to represent one
byte. That is, positions of the right hand side vertical
bars are not aligned at the same column. They should be
printed in the same column.
Please use one byte notation to represent the first byte of
a multibyte character.
WG14: Response Code: EY
-----------------------------------------------------------------
2.17 Wrong conversion specifier in the example of fprintf
@ Subclause "7.13.6.1 The fprintf function" Examples
Page 294, line 6 in paragraph 18:
"%13.1ls" should be corrected to "%13.11ls".
(The original Amendment 1 has the same mistake.)
WG14: Response Code: EY
-----------------------------------------------------------------
2.18 The bahavior of a successful call to fseek and fsetpos
@ Subclause "7.13.9.2 The fseek function"
Page 317, paragraph 5:
@ Subclause "7.13.9.3 The fsetpos function"
Page 317, paragraph 3:
The description about the behavior of a successful call to
the fseek function was made clear in the current CD (SC22
N2620). However, the description of fsetpos about a
successful call was not changed from the ISO/IEC 9899.
The behavior of successful call to fseek should be same as
fsetpos.
Please update the description about the behavior of a
successful call to fsetps in the same way of fseek.
WG14: Response Code: EY
-----------------------------------------------------------------
2.19 The redundunt sentences in mktime()
@ Subclause: 7.16.2.3 The mktime function
page 360, paragraph 3-6:
The lst sentence in the paragraph 5 and all sentences in
the paragraph 6 are entirely the same as all sentences of
the paragraph 3 and 4. The last sentence in paragraph 5 and
all sentences in paragraph 6 should be dropped.
WG14: Response Code: EY
-----------------------------------------------------------------
2.20 Missng iswblank() in the description of iswctype()
@ Subclause "7.18.2.2.2 The iswctype function"
Page 377, paragraph 3:
Please add "iswctype(wc, wctype("blank")) // iswblank(wc)"
WG14: Response Code: SD
isblank and iswblank were not approved and should not have
appeared in the draft.
-----------------------------------------------------------------
2.21 Incorrect parameter type of the nextafterx function
@ Annex "D.9 Mathematics <math.h>"
Page 465, line 15-16:
The "nextafterxf" and "nextafrerxl" functions are declared
as follows.
float nextafterxf(float, long float);
long double nextafterxl(long double, long long double);
Each second parameter shall have type "long double".
WG14: Response Code: EY
-----------------------------------------------------------------
2.22 Descriptions for some functions are not found
@ Annex "F.9.3 Exponential and logarithmic functions"
Page 499-501:
A description for "scalbln" function is not found.
@ Annex "F.9.6 Nearest integer functions"
Page 503-505:
A description for "llrint" and "llround" functions are not
found.
@ Annex "F.9.8 Manipulation functions"
Page 506:
A description for "nextafterx" function is not found.
WG14: Response Code: AD
These descriptions have been added to the
appropriate Annex.
-----------------------------------------------------------------
2.23 No more "common warning"
@ Annex "J Common Warnings"
Page 530, paragraph 2:
Following warning is no more "common warning".
- A function has return statements with and without
expressions.
In subclause 6.6.6.4 Return statement(page 147),
"Constrains" has been changed from previous draft and
the following second sentence is appended:
A return statement with an expression shall not
appear in a function whose return type is void.
A return statement without an expression shall only
appear in a function whose return type is void.
This means a function shall not have return statements both
with and without expression. It is an undefined behavior.
WG14: Response Code: EY
-----------------------------------------------------------------
2.24 Incomplete Annex K Portability issues
@ "Annex K Portability issues"
Page 532-554
Undefined/unspecified/implementation-defined behaviors
descreibed in "Amendment 1" are not included in the Annex
K1-K3. Please add the summary of them to Annex K1-K3.
WG14: Response Code: M
The committee believes they have been included -- similar
topics are grouped together in annex K, so the wide
functions appear with the corresponding narrow functions
rather than having separate entries.
-----------------------------------------------------------------
3. Further Comments on SC22 N2618
---------------------------------
Japan has further comments on some of SC22/WG14's
dispositions described in SC22 N2618 (Disposition of Comments
Report on CD Registration for CD 9899: Informationtechnology -
Programming languages - Programming Language C (Revision of
ISO/IEC 9899:1993)).
3.1 The 64 bit data type should be optional
> 1. Technical Comments
> 1) Type long long int and lldiv_t should be optional.
>
> Paragraph 1 of subclause 5.2.4.1 (page 19 in draft 9),
> paragraph 3 of subclause 6.1.2.5 (page 32 in draft 9),
> constraints of subclause 6.5.2 (page 83 in draft 9), and
> paragraph 2 of subclause 7.13 (page 258 in draft 9):
>
> Type (unsigned) long long int is introduced into the draft 9
> as a mandatory part of the standard C. The maximum and
> minimum values for an object of type (unsigned) long long
> int are defined in the subclause 5.2.4.2. These values need
> to be represented by using 64 bit data type. Implementation
> of type (unsigned) long long int, however, is too hard for
> the compiler on the currently widely used 16 or 32 bit
> architecture machines. The cross compiler on the small
> machine must especially face a big difficulty when
> implementing type (unsigned) long long int. Therefore,
> type (unsigned) long long int should be a part of an
> optional specification or a part of the common extension of
> the standard C.
>
> A new type lldiv_t defined in subclause 7.13 should be
> reconsidered as well as type long long int.
>
> WG14: The Committee believes that the current WD is specifing current
> pracitice. The Committee also believes that the benifit to the user
> community out weights the cost of implementation for this feature.
>
Japanese original comment is not proposing to drop the
specification of the type long long int at all. Japanese
comment does not intend "all-or-nothing" about long long
int. Japan is just proposing that "the 64 bit data type"
should be OPTIONAL, not mandatory. The above WG14's
disposion does not seem to explain an appropriate reason to
dispapprove "optional."
Japan, of course, knows well that there are the users who
need the 64 bit data type and also knows well it is possible
to implement the 64 bit data type even on the 16 or 32 bit
architecture machine even if it is a hard work, however, a
population of the 64 data type users are NOT the whole of
the C language user community. Japan thinks that there are
still significant nubmers of users who must be in trouble
with an unnecessary FAT implementation of the mandatory 64
bit data type.
Actually, for example, there are lots of developers and
vendors of small embeded system who are imposed to use or
develop "the ISO C comforming implememtaion" by their
customers/cliants or employers even if the 64 bit date is
comletely unnecessary to develop their system. In this
case, the 64 bit data type is just only a heavy burden
for them. The implementation of 64 bit data type is not the
benefit to this kind of users community at all. This is
just one of the examples.
So, Japan thinks that the words "the benifit to the user
community" in WG14's disposition does not express the real
situation. Correctly speaking, in the user community, there
are people who get the benefit from the 64 bit data type,
but, on the other hand, there are still a lot of people who
feel a disadvantage in the fat implementation of the 64 bit
data type.
So, please reconsider to make the 64 bit datat type
optional. (Japan does NOT mean to drop the long long int
itself.)
WG14: Response Code: PR
-----------------------------------------------------------------
3.2 The function atoll() is redundant as the ISO C language
standard
> 1. Technical Comments
> 3) Function atoll() should be dropped.
>
> Subclause 7.13.1.4 (page 260 in draft 9):
>
> A new function atoll() is redundant for the standard C.
> (Every ato*() functions can be replaced by strto*().)
> The functions which can be directly replaced by other
> functions should not be included in the standard C. Not
> introducing redundant functions was one of the important
> policies of development of the Amendment 1. This policy is
> clearly described in the annex B.3 of the Amendment 1. If
> the committee had determined to include the function atoll()
> by some strong reason, why are NOT atod(), atold() included
> in the draft 9? Please drop atoll() from the draft, or please
> document a clear rationale which describes the reason why only
> atoll() was added.
>
> WG14: The Committee discussed this, and believes that this feature
> is currently existing practice. The consensus of the Committee
> is that the simple interface of this function is usefull to the
> user community.
Japan can not agree a direct addition of extra function only
by the simple reason "it is currently existing practice" and
"the simple interface of it is useful to the user
community." If "the simple interface is usefull to the user
community" is so importnat, why atod() and atold() are not
added? The atod() and atold() provide the simple interface
to the user community as well as atoll(). It seems there is
no policy and no criteria to make the language standard
here. Introducing new ato*() to the ISO C standard is
apparently break "the spirit of C" described in the Charter
of C9X:
- Keep language small and simple
- Provide only one way to do an operation
Japan requests again here:
Please drop atoll() from the draft, or please document a
CLEAR RATIONALE which describes the reason why ONLY atoll()
was added and the reason why other ato*() are NOT added.
Please make the criteria of intorduction of new functions
clear.
WG14: Response Code: PR
-----------------------------------------------------------------
3.3 Example of ## operator
> 1. Technical Comments
> 5) Illegal example of ## operator
>
> Paragraph 4 (example) of subclause 6.8.3.3 (page 131 in
> draft 9):
>
> In the Example of the ## operator(paragraph 4 of
> subclause 6.8.3.3 (page 131)), that is,
> -----------------------------------------------------
> #define hash_hash # ## #
> #define mkstr(a) # a
> #define in_between(a) mkstr(a)
> #define join(c, d) in_between(c hash_hash d)
>
> char p[] = join(x, y); /* equivalent to */
> /* char p[] = "x ## y"; */
>
> The expansion produces, at various stages:
>
> join(x, y)
>
> in_between(x hash_hash y)
>
> in_between(x ## y) ---- line (A)
>
> mkstr(x ## y)
>
> "x ## y"
> -----------------------------------------------------
>
> an object-like macro "hash_hash" is replaced by "##" at
> line (A). Well then, what kind of preprocessing-token is
> the "##" at line (A)?
>
> First, we can not find out any preprocessing-token other
> than "operator" for ##, therefore, the ## at line (A)
> must be the operator. Right? If so, the following
> description in the example must be incorrect:
> In other words, expanding hash_hash produces a new
> token, consisting of two adjacent sharp signs, but
> this new token is not the catenation operator.
>
> This description certainly says that ## is a token, but
> it is not the operator.
>
> Well, for the above description, should we read like
> the following sentence?
> ...this new token is the operator as
> preprocessing-token, but does not function as the
> catenation operator.
>
> Even if so, this situation violates the Constraints of
> subclause 6.1.5 "Operator"(page 45 in draft 9) unless
> "##" in line (A) is considered as an operator:
> The operators # and ## shall occur in macro-defining
> preprocessing directives only.
>
> If we think a case that "##" is not a single
> preprocessing-token, then a behavior of this example must
> be undefined because of a paragraph 3 of subclause 6.8.3.3
> "the ## operator" (page 130 in draft 9):
> If the result is not a valid preprocessing token,
> the behavior is undefined.
>
> Anyway, whichever we choose, that is, the violation of
> the constraints or the undefined behavior, this example
> is not suitable for the example of the standard C.
>
> WG14: The current WD has new preprocessor token wording, that
> the Committee believes make the WD clearer in the area.
> The example is correct.
There are NO improvement about this problem in the current
CD (SC22 N2620.)
Please refer to:
"6.1.5 Operators", page 56, line 2-3 in paragraph 2:
> The operators # and ## (also spelled %: and %:%:, respectively)
> shall ocure in macro defining preprocessing directives only.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"6.8.3.3 The ## operator", page 163, line 8-9 in paragraph 3:
> If the result is not a valid preprocessing token,
> the behavior is undefined.
These specifications still inconsistent with the description
of the example.
Japan requests again here:
Please reconsder carefully the above issue.
WG14: Response Code: SD
-----------------------------------------------------------------
3.4 Old reference to ISO/IEC 646
> 2. Editorial Comments
> 1) The reference ISO/IEC 646:1983 must be ISO/IEC 646:1991.
>
> Paragraph 1 of clause 2 (page 2 in draft 9):
>
> The normative reference for ISO 7-bit codes character set is
> defined as ISO 646:1983. That is old. It must be the
> latest one ISO/IEC 646:1991.
>
> WG14: The WD will be corrected.
The clause "2 Normative references" of the current CD(SC22
N2620) still referes to ISO/IEC 646:1983. The Annex A
"Bibliography" also refers ISO/IEC 646:1983.
Japan requests again here:
Please correct them.
WG14: Response Code: EY
-----------------------------------------------------------------
3.5 Locale-specific behavior
> 2. Editorial Comments
> 2) Locale-specific behavior
>
> Paragraph 4 of Clause 4 (page 6 in draft 9):
>
> The description "an implementation shall be accompanied by a
> document that defines all implementation-defined
> characteristics and all extensions." should also mention
> "the locale-specific behavior" which is defined in the
> subclause 3.13.
>
> WG14: The WD will be corrected.
There is no correction in the current CD (SC22 N2620).
Please correct it.
WG14: Response Code: EY
-----------------------------------------------------------------
3.6 Terminology of a null character
> 2. Editorial Comments
> 4) Terminology of a null character
>
> A many variety of the representation of "null character"
> is used in the draft 9.
> For example,
> - A byte with all bits zero, subclause 5.2.1.2 (page 17)
> - '\0', subclause 6.1.3.4 (page 43)
> - code of value zero, subclause 6.1.4 (page 44)
> - \0 escape sequence, footnote 33 (page 44)
> - zero-valued code, subclause 6.5.7 (page 104)
> - code value zero, subclause 7.1.1 (page 139)
> - code with value zero, subclause 7.13.8.1 (page 277)
> - terminating zero code, subclause 7.13.8.1 (page 278)
>
> So, they should be represented by using a same term.
>
> WG14: The Committee discussed this issue, and reached the consensus
> that a more detailed proposal would be needed to make such a
> major change.
In the current CD (SC22 N 2620):
1) Subclause "6.5.8 Initialization"
Page 133, line 3 in paragraph 18:
"(including the terminating zero-valued code...)"
should be changed to
"(including the terminating null wide character (defined
in 7.1.1)...)"
2) Subclause "7.14.8.1 Multibyte string functions" Returns
Page 343, line 3 in paragraph 4:
"terminating zero code"
should be changed to
"terminating null character (defined in 5.2.1)"
WG14: Response Code: AL
-----------------------------------------------------------------
3.7 Placemaker
> 2. Editorial Comments
> 5) Placemaker should be included in preprocessing token.
>
> Paragraph 1 (syntax) of Subclause 6.1 (page 26 in draft 9):
>
> Placemaker defined in 6.8.3.2 is not included in
> the syntax of preprocessing token. It should be included.
>
> WG14: The "placemarker" preprocessing tokens are conceptually
> introduced during translation phase 4 and are conceptually
> removed before the end of phase 4; their only function is
> to ensure that empty macro arguments are distinct entities
> during macro replacement, rather than vanishing too soon.
> Because "placemarker" preprocessing tokens cannot exist
> in the program source file, it would be inappropriate and
> confusing to show them in the formal grammar.
Japan requests to add the WG14's above explanation as a
footnote of placemarker.
WG14: Response Code: AL
-----------------------------------------------------------------
3.8 A double argument for the conversion specifier
> 2. Editorial Comments
> 14) A double argument for the conversion specifier
>
> Subclause 7.12.6.1 (page 232 - 233 in draft 9) and
> subclause 7.18.2.1 (page 308 - 309 in draft 9):
>
> In the description about the conversion specifier f, F, e,
> E and G of the function f[w]printf,
> "a double argument representing a floating-point number
> is..."
> should be changed to
> "a double argument representing a normalized
> floating-point number is..." ^^^^^^^^^^
> in order to clarify the range and the definition of the
> double argument.
>
> WG14: The Committee discussed this comment, and came to the
> consensus that this is not an editoral issue, some floating
> point arithmetics support denormal numbers and infinities.
> There will need to be a detailed proposal to support this
> change.
The original intention of Japanese comment is to point out
that the current description:
"A double argumant representing a floating number is
converted to ...[-]ddd.ddd...
A double argument representing an infinity is converted
to ...[-]inf or [-]infinity
A double argument representing a NaN is convered to ...
[-]nan or [-]nan(n-char-sequence)..."
is not appropriate as a strict language standard
specification because "a floating-pount number" (defined in
"5.2.4.2.2 Characteristics of floating types <float.h>"),
as WG14 mentions above, may include an infinity and a Nan
so that the current description can be reasd as an infinty
can be converted to [-]ddd.ddd or [-]inf and also NaN can be
converted to [-]ddd.ddd or [-]Nan.
Therefore, Japan re-proposes to change the above description
to:
"A double argument representing an infinity is converted
to ...[-]inf or [-]infinity...
A double argument representing a NaN is converted to ...
[-]nan or [-]nan(n-char-sequence)..."
A double argumant representing a floating number except
an infinity and a NaN is converted to ...[-]ddd.ddd..."
This change should be applied to the description about the
conversion specifier f, F, e, E and G of the function
f[w]printf().
WG14: Response Code: AL
-----------------------------------------------------------------
United Kingdom
WG14: The following 6 statements are all resolved in the UK Public
Comments that follow.
Consideration should be given to the following:
(1) Change "complex" to be a true keyword.
(2) Remove the keyword "imaginary".
(3) Change the semantics of the keyword "restrict" to provide better
facilities for optimization. In brief, replace the present "simple lock"
semantics with "write once or read multiple" semantics.
(4) Remove the "long long" type, and reinstate the concept that "long" is
the longest integer type.
(5) Adjust the wording concerning multiple representations of the same
value for both integer and floating types where these are distinguishable,
and to require constants to generate consistent representations.
(6) The changes introduced in the floating-point model, in particular
with respect to exception handling, should be reconsidered
In addition, to the above points the UK is submitting the following
comments for consideration by WG14 These describe other issues that
should be addressed in the CD, while no one individual comment is
critical, the total number form a significant issue for the UK vote.
Public Comment Number PC-UK0001
Category: Editorial change/non-normative contribution
Committee Draft subsection: various
Title: Errors in applying working papers to CD1
Detailed description:
This document lists the errors that have been made applying my approved
papers in CD1. They are listed in this Public Comment for the record.
N672 has not been applied.
The change to translation phase 2 in N673 has been made, but the footnote
has been lost.
7.1.8p3 should read "... returns.", not "... return"; see N675 DR147 for
details. The same correction is needed in annex C.
Footnote 30 should read "... and is not compatible with either.", not
"and it not compatible with either.". The change was introduced in N739
item 6a.
6.5.2p4 should read "... the specifier /int/ ...". The change was
introduced in N739 item 10.
7.16.3.6p6 should read "%p", not "%P" (this was introduced in N674 part
G). It is also inconsistent in its use of fonts - compare %B and %p.
7.11p3 has been misedited; it reads:
... which expand to positive integer constant expressions with type
/int/ and distinct values that have type compatible ... which expand to
positive integer constant expressions with distinct values that
are the signal numbers ... and should read:
... which expand to constant expressions with distinct values that
have type compatible ... which expand to positive integer constant
expressions with type /int/ and distinct values that are the signal
numbers ...
The change was introduced in N773 item 9B.
6.3.15p4 to p6 have not been changed as required by N774 item 1.
6.5.2.3p4 should read "The type is incomplete[94]", not "The type is
complete[94]". The change was introduced in N774 item 5.
Footnote 227 is missing the last line:
(char *) p < (char *) base + nmemb * size
The change was introduced in N783 item 13.
The changes relating to _exit() in N789 were omitted (at the discretion
of the editorial committee).
These will be resubmitted as a separate Public Comment.
7.16.1p1 should read "... and declares five types ...", not "... and
declares four types ...". The change was introduced in N793.
The comment within the pseudo-code in 7.16.2.6p3 is missing the last
line, which should read:
// if the offset cannot be determined.
The change was introduced in N793, though this also seems to be missing
that line.
WG14: Response Code: EY
-----------------------------------------------------------------
Public Comment Number PC-UK0002
Category: Other: correction restoring original intent
Committee Draft subsection: 6.5.2.1
Title: Padding in unions - wording adjustment
Detailed description:
6.5.2.1p14 no longer makes sense. The words:
were the structure or union to be an element of an array should be
deleted.
WG14: Response Code: EY
-----------------------------------------------------------------
Public Comment Number PC-UK0003
Comment 1.
Category: Normative change to existing feature retaining the original
intent Committee Draft subsection: 6.3.2.2
Title: Adjustment to permitted incompatible argument types
Detailed description:
The excepted cases in 6.3.2.2p5 were meant to be slightly less
restrictive than the wording given. The second bullet point should read:
- both types are pointers to qualified or unqualified versions of
/void/ or of character types.
In addition, paragraph 6 should be part of paragraph 5; it is easy to
misparse the present arrangement. It could also be made easier by changing
the first words of the paragraph to: Furthermore, if the function ...
WG14: Response Code: NI
-----------------------------------------------------------------
Public Comment Number PC-UK0004
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.7
Title: Shift operators - wording tidy up
Detailed description:
Now that the term "width" is available, 6.3.7p3 could be reworded; the
last sentence should read:
If the value of the right operand is negative or is greater than or
equal to the width of the promoted left operand, the behavior is
undefined.
WG14: Response Code: EY
-----------------------------------------------------------------
Public Comment Number PC-UK0005
Comment 1.
Category: Normative change to existing feature retaining the original
intent Committee Draft
subsection: 3.18, 6.8.5
Title: Make #error have the desired effect
Detailed description:
Consider the program:
#error foo
int main(void) { return 0; }
This does not violate any of 3.18p3:
The implementation must successfully translate a given program unless
a syntax error is detected, a constraint is violated, or it can determine
that every possible execution of that program would result in undefined
behavior but clearly ought to. A reasonable way to fix this is to add to
the end of 3.18p3:
The implementation must not successfully translate a program that
contains a #error preprocessing directive that is not part of a group
that is skipped by conditional inclusion.
WG14: Response Code: Y
-----------------------------------------------------------------
Public Comment Number PC-UK0006
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.4
Title: Clarification concerning overlapping string literals
Detailed description:
The first sentence of 6.1.4p6 does not fall into any of the three types
of behavior. Better wording would be:
It is unspecified whether these arrays overlap or not, provided that
their characters have the appropriate values.
WG14: Response Code: EY
-----------------------------------------------------------------
Public Comment Number PC-UK0007
Comment 1.
Category: Other: outstanding problem
Committee Draft subsection: 6.5.3.1
Title: Problem with restrict and string literals
Detailed description:
Consider the function call:
fopen ("bar", "r");
Because both parameters of open() have restrict-qualified type, it is not
permitted for the two strings to share storage. However, an implementation
which shares string literals might do so, possibly without the programmer
realizing that the situation happened (for example, the first parameter
might be a macro defined in a makefile).
The correct solution is to exempt string literals from the rules
concerning restrict, but I am not familiar enough with the wording to try.
WG14: Response Code: DA
The restrict qualifiers have been removed from functions
like fopen.
-----------------------------------------------------------------
Public Comment Number PC-UK0008
Comment 1.
Category: Other: moving normative text to a normative section
Committee Draft subsection: Introduction, 1
Title: The definition of normative text should be normative.
Detailed description:
The Introduction contains the text:
The introduction, the examples, the footnotes, the references, and
the annexes are not part of this International Standard.
However, this text is not normative, and so it is not clear what text is
and is not normative. It is alss wrong.
Delete the sentence from the Introduction. Add a new paragraph 3 to
clause 1:
Annexes F and I are normative. The introduction, the examples, the
footnotes, the references, and the remaining annexes are not part of this
International Standard.
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0009
Comment 1.
Category: Inconsistency
Committee Draft subsection: 7.16.3.6
Title: Lacuna in strftime() %z
Detailed description:
The description of %z does not say what to do if no time zone can be
determined. After the parenthesized clause, insert the words:
or no characters if no time zone is determinable.
WG14: Response Code: EY
-----------------------------------------------------------------
Public Comment Number PC-UK0010
Comment 1.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 7.16.1
Title: _NO_LEAP_SECONDS should require a sensible value
Detailed description:
After the symbol _NO_LEAP_SECONDS in 7.16.1p2, add the comment:
_NO_LEAP_SECONDS // must be outside the range [-3600, +3600]
WG14: Response Code: Y
-----------------------------------------------------------------
Public Comment Number PC-UK0011
Comment 1.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 7.16.1
Title: require a type for _NO_LEAP_SECONDS and _LOCALTIME.
Detailed description:
At the end of 7.16.1p2 add the words:
which are integral constant expressions with type /int/.
WG14: Response Code: Y
-----------------------------------------------------------------
Public Comment Number PC-UK0012
Comment 1.
Category: Inconsistency
Committee Draft subsection: 7.16.1
Title: Fix definition of "broken-down time".
Detailed description:
The term "broken-down time" is clearly intended to refer to both the
types "struct tm" and "struct tmx". Change the last part of 7.16.1p3 from:
... representing times;
/struct tm/
which holds the component of a calendar time, called the /broken-down
time/; and /struct tmx/ which is an extended version of /struct tm/.
to:
... representing times; and
/struct tm/
and
/struct tmx/
which hold the components of a calendar time, called the /broken-down
time/, in two slightly different ways.
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0013
Comment 1.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 6.1.2.5, 6.5.2.1
Title: Cleanup of flexible array structure members.
Detailed description:
The concept of flexible array structure members, otherwise known as the
"struct hack", has a number of minor problems that need fixing.
Furthermore, there are some nasty implications when such a structure is
used as a component of an aggregate type, this is forbidden.
6.1.2.5p17, bullet point 2, should read:
A /structure type/ describes a sequentially allocated nonempty set of
member objects (and, in certain circumstances, an incomplete array), each
of which has an optionally specified name and possibly distinct type.
6.5.2.1p2, first sentence, should read:
... except that the last member of a structure with more than one
named member may have incomplete array type; such a structure (and any
union containing, possibly recursively, a member whose type is such a
structure) shall not be the type of a member of a structure or of the
element of an array.
6.5.2.1p15 should be replaced by:
As a special case, the last member of a structure with more than one
named member may have an incomplete array type. This is called a /flexible
array member/, and the size of the structure shall be equal to the offset
of the last member of an otherwise identical structure that replaces the
flexible array member with an array of unspecified length [*]. When an lvalue
whose type is a structure with a flexible array member is used to access
an object, 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
that element.
[*] The length is unspecified to allow for the fact that some
implementations may give array members different alignments according to
their length.
Change the start of paragraph 16 to:
Assuming that all arrays have the same alignment within structures,
then after the declarations:
struct s { int n; double d[]; };
struct ss { int n; double d[42]; };
the three expressions:
In paragraph 17, change:
/s1/ and /s2/ behave as if they had been declared as:
to:
the objects pointed to by /s1/ and /s2/ behave as if the latter two
identifiers had been declared as:
WG14: Response Code: Y
-----------------------------------------------------------------
Public Comment Number PC-UK0014
Comment 1.
Category: Inconsistency
Committee Draft subsection: 6.5.8
Title: problems with initializing unsigned char arrays.
Detailed description:
Consider the following declaration:
unsigned char s [] = "\x80\xff";
The first element of the string literal has the value:
(char) 128
and the second element has the value:
(char) 255
If the type char is signed and CHAR_MAX is less than 128, these two
expressions are implementation-defined. In particular, on a
ones-complement implementation likely values are -127 and -0 respectively.
When these are converted back to unsigned char during the initialization,
then (if UCHAR_MAX is 255) they will be converted to 129 and 0
respectively. This is *not* intuitive.
Append to 6.5.8p17:
The value of each element is determined by converting the
corresponding numerical representation of the mapped character, or the
octal or hexadecimal escape sequence, directly to the array element
type, not via the type char.
Append to example 7 in 6.5.8p24:
The declaration:
unsigned char c [] = "\xFF";
is identical to:
unsigned char c [2] = { 0xFF, 0 };
and not to:
unsigned char c [2] = { (unsigned char)(char) 0xFF, 0 };
(the latter could be different if /CHAR_MAX/ is less than 255 and the
implementation-defined value of the expression /(char) 0xFF/ is not equal
to /254-UCHAR_MAX/).
WG14: Response Code: NC
-----------------------------------------------------------------
Public Comment Number PC-UK0015
Comment 1.
Category: Feature that should be included
Committee Draft subsection: 5.2.4.2.1
Title: ensure int can hold all characters and EOF
Detailed description:
To eliminate a pathological case, append to 5.2.4.2.1p2:
On a hosted implementation, INT_MAX shall be not less than UCHAR_MAX.
WG14: Response Code: N
-----------------------------------------------------------------
Public Comment Number PC-UK0016
Comment 1.
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.1.1
Title: eliminate conditional keywords
Detailed description:
6.1.1 makes the keywords "complex" and "imaginary" only be "reserved" if
the header <complex.h> is included. This is a problem for two different
reasons.
Firstly, cautious programmers will assume that the keywords might be
needed at some later date, for example by a system header that they have
no control over. Therefore they will have to play safe and not use them.
The less cautious may use them, and then be burnt later when such a
change outside their control happens. Both cases bring the Standard into
disrepute.
Seeing that the decision has already been made to introduce new keywords,
there is little benefit in this approach unless it is going to be more
radical (for example, making complex types be unavailable on freestanding
implementations). And, even so, there are better approaches.
Secondly, the term "reserved" is being misused. This term (see 7.1.3)
means that an identifier may not be redeclared. Keywords are not
identifiers, and thus reservation is nonsense. In any case, the syntax
does not allow a keyword to be used as if it were an identifier.
Three alternatives are given here; my preference is for the third.
Alternative 1: delete 6.1.1 paragraph 2.
Alternative 2: if it is still viewed as desirable to make the names
"complex" and "imaginary" available to programmers not using <complex.h>,
then:
* Change the keywords in 6.1.1 to __complex and __imaginary.
* Add to 7.8 a new paragraph 4:
The macro /complex/ is defined to be /__complex/. If and only if the
macro /_Imaginary_I/ is defined, then the macro /imaginary/ is defined to
be /__imaginary/. Notwithstanding the provisions of subclause 7.1.3, it is
permitted to undefine the macros /complex/ and /imaginary/.
Alternative 3: since complex types are basic to the language while
imaginary types are an extension:
* Change the keyword imaginary in 6.1.1 to __imaginary.
* Add to 7.8 a new paragraph 4:
If and only if the macro /_Imaginary_I/ is defined, then the macro
/imaginary/ is defined to be /__imaginary/. Notwithstanding the provisions
of subclause 7.1.3, it is permitted to undefine the macro /imaginary/.
WG14: Response Code: DA
The identifiers "_Complex" and "_Imaginary" are always
keywords now.
-----------------------------------------------------------------
Public Comment Number PC-UK0017
Comment 1.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 6.3.9
Title: fix pointer comparison
Detailed description:
DR 172 addressed a number of defects in the rules for pointer comparison,
and the DR authors suggested new wording to fix this. This issue was also
raised in WG14 papers N720 and N783. Following other changes in the
Standard, this wording is no longer completely acceptable. Instead,
replace 6.3.9 paragraphs 3 to 5 with the following text.
The == (equal to) and != (not equal to) operators are analogous to
the relational operators except for their lower precedence.[78] They yield
1 if the specified relation is true and 0 if it is false. The result has
type /int/. For any pair of operands, one operator shall be true and the
other false.
If both of the operands have arithmetic type, the usual arithmetic
conversions are performed. [[Insert the existing paragraph 5 here.]]
Otherwise the operands are pointers; if one is a pointer to an object or
incomplete type and the other has type pointer to a qualified or
unqualified version of /void/, the former is converted to the type of the
latter.
Two pointers shall compare equal if both are null pointers, both are
pointers to the same object (including a pointer to an object and a
subobject at its beginning), the same element of an array object, or the
same function, if both are pointers to one past the end of the same array
object, or if one is a pointer to one past the end of one array object and
the other is a pointer to the start of a different array object that
happens to be immediately after it in the address space.[79] Otherwise
they shall compare unequal.
Prepend to footnote 79:
Two objects may be adjacent in memory because they are adjacent
elements of some larger array object, because they are adjacent members of
a structure with no padding between them, or because they are unrelated
and the implementation chooses to place them adjacent in memory.
WG14: Response Code: Y
-----------------------------------------------------------------
Public Comment Number PC-UK0018
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.2.7, 6.3.1.1
Title: merge predefined identifiers into one place
Detailed description:
The concept of predefined identifiers is found in two separate places:
6.1.2.7 and 6.3.1.1. The latter location is, I believe, historical cruft
from when __func__ was treated as a special entity. It would read
better to merge the two sections into one, and 6.1.2.7 is a better
location.
Delete subclause 6.3.1.1. Replace subclause 6.1.2.7 by the following:
6.1.2.7 Predefined identifiers
The identifiers described in the following subclauses shall be
implicitly defined by the implementation.
6.1.2.7.1 The identifier __func__
[[Insert the body of the present 6.3.1.1 here.]]
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0019
Comment 1.
Category: Request for information/clarification
Committee Draft subsection: 5.1.1.2, 6.3.1.1
Title: handling of characters not in the execution character set
Detailed description:
Consider the code extract:
char *s = "\u30CE";
During translation phase 5 the universal character name is converted to a
multibyte character. However, it is not stated what happens if the
implementation does not have a representation for Katakana (30CE is within
the Katakana range of annex I). Therefore it is implicitly undefined.
Now consider the following translation unit:
#include <stdio.h>
void fff (void);
void \u30CE (void);
int main (void)
{
fff ();
\u30CE ();
return 0;
}
void fff (void)
{
printf ("This is %s\n", __func__);
}
void \u30CE (void)
{
printf ("Hello world!\n");
}
This is clearly strictly conforming (unless I've made an error :-).
Now consider the trivial change:
#include <stdio.h>
void fff (void);
void \u30CE (void);
int main (void)
{
fff ();
\u30CE ();
return 0;
}
void fff (void)
{
printf ("Hello world!\n");
}
void \u30CE (void)
{
printf ("This is %s\n", __func__);
}
This is now undefined on any implementation that cannot represent the
Katakana character set ! I have trouble believing that this was intended,
and I certainly feel that, if it is retained, it should be flagged in the
text of the Standard.
WG14: Response Code: SD
See WG14 N837 UCN handling.
-----------------------------------------------------------------
Public Comment Number PC-UK0020
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 4
Title: Adjust wording of footnote 2
Detailed description:
Footnote 2 is not particularly clear. Better wording would be:
A strictly conforming program can use conditional features, such as
those in annex F, provided that the use is guarded by an #ifdef directive
with the appropriate macro. For example:
[[followed by the existing example]]
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0021
Comment 1.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 4
Title: Further requirements on the conformance documentation
Detailed description:
There are many things that the Standard requires to be documented, but
not all of them are listed in 4p4. Change it to:
An implementation shall be accompanied by a document that describes
all features that this International Standard requires to be described by
the implementation, including all implementation-defined characteristics
and all extensions.
WG14: Response Code: NC
-----------------------------------------------------------------
Public Comment Number PC-UK0022
Comment 1.
Category: Inconsistency
Committee Draft subsection: 5.1.1.2
Title: Translation phase 6 is inconsistent
Detailed description:
Change TP 6 in 5.1.1.2p1 to read:
Adjacent character string literal tokens and wide string literal
tokens are concatenated.
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0023
Comment 1.
Category: Inconsistency
Committee Draft subsection: 6.5.2.1, 6.5.6
Title: Removing implicit int, further lacunae
Detailed description:
The requirement for a type specifier has been omitted from 6.5.2.1 and
6.5.6. In each case, add a constraint:
At least one type specified shall be given in each
specifier-qualifier-list.
WG14: Response Code: EY
-----------------------------------------------------------------
Public Comment Number PC-UK0024
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.2.5
Title: Replace footnote 25
Detailed description:
Footnote 25 is unclear in context. A better description of the situation
is in footnote 29. Replace the text of FN25 with that of FN29, and change
all references to the latter to be references to the former.
WG14: Response Code: CE
-----------------------------------------------------------------
Public Comment Number PC-UK0025
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.3.2
Title: clarify the explanation of the types of an integer constant
Detailed description:
6.1.3.2p5 is rather difficult to read. Better would be to replace it with
a table, like this:
The type of an integer constant is the first one marked with an X in
the corresponding column of the table in which its value can be
represented:
Suffix: - - U L L LU LL LL LLU
Base: D O/H - D O/H - D O/H -
signed int X X
unsigned int X X
signed long X X X X
unsigned long X X X X
signed long long X X X X X X
unsigned long long X X X X X X
/signed extended/ X X X
/unsigned extended/ X X X
/any extended/ X X X
Notes: suffixes may be in either case, and where there are two
suffixes, in either order.
D = decimal
O/H = octal or hexadecimal
If an integer constant cannot be represented by any standard type in
its list, it may be represented by an extended integer type if there is
one that can represent that value. The type must be signed or unsigned if
so indicated.
Alternatively, the ad hoc nature of the present description could be
replaced by one more structured:
The type of an integer constant is the first one in the following
list in which its value can be represented:
/signed int/, /unsigned int/,
/signed long int/, /unsigned long int/,
/signed long long int/, /unsigned long long int/
and subject to the following restrictions:
- if suffixed by /u/ or /U/, then omit the signed types
- if decimal and not suffixed by /u/ or /U/, then omit the unsigned
types
- if suffixed by /l/ or /L/, then omit the first pair
- if suffixed by /ll/ or /LL/, then omit the first two pairs
If an integer constant cannot be represented by any of the types
permitted by the above, it may be represented by an extended integer type
if there is one that can represent that value and which has the same
signedness as at least one of the permitted standard types.
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0026
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.1.4
Title: improve the example of character string literals
Detailed description:
Append to 6.1.4p7, the example:
When this is used to initialize a static array, the array has three
members that are initialized to /18/, the value of /'3'/, and /0/
respectively.
WG14: Response Code: EN
-----------------------------------------------------------------
Public Comment Number PC-UK0027
Comment 1.
Category: Inconsistency
Committee Draft subsection: 5.1.1.2, 5.2.1, 5.2.1.2, 6.1.2, 6.1.2.5, 6.8
Title: inconsistencies in use of "basic" and "extended" character sets
and in their relationship to UCNs
Detailed description:
The Standard uses the terms "basic character set" and "extended character
set" at various places. However, the exact meaning of these two is not
clear, and this leads to confusion.
Consider the UTF-8 encoding (codes from 0 to 127 are single byte, codes
from 128 to 255 form part of multibyte characters with length from 2 to 5
bytes). There are five possible execution character sets:
[1] The 95 characters required by 5.2.1p3, plus the null character.
[2] The 128 single byte characters.
[3] The 2**31 multibyte characters.
[4] Set [3] minus set [1].
[5] Set [3] minus set [2].
(and corresponding source sets).
It is unclear whether the "basic character set" means [1] or [2]. The use
of the wording "at least the following members" in 5.2.1p3 implies that
the basic set can be larger than [1]. On the other hand, if the term is
taken to represent [2], then 5.1.1.2p2 would forbid using \u0040 to
represent the @ sign, something which I do not believe was intended, since
it means that the \u form would be forbidden for *all* characters in the
implementation-defined "basic" set.
Consideration of this and related matters has led me to believe that it
is most useful to have terms for [1] and for [4], while on the other hand
there is little or no need to refer to [2], [3], and [5]. Therefore
"basic character set" should represent [1] and "extended character set"
should represent [4]. To do this requires a number of changes.
Replace 5.2.1p1, second sentence, by:
Each set is further divided into a /basic/ set, whose contents are
given by this subclause, and an /extended/ set, consisting of zero or more
locale-specific members (which are not members of the basic 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".
Delete the last sentence of 5.2.1p3 ("If any other characters ... the
behavior is undefined"). It is useless for several reasons:
- If translation phase 1 is taken literally, all members of the extended
character set are replaced by UCNs, which consist of members of the basic
character set (this point is further addressed below). While some are
converted back in translation phase 5, all such characters are included
in the exemptions.
- It does not allow for UCNs in identifiers.
- If such a character was encountered, the preprocessing token it is in
is either not converted to a token (in which case the sentence does not
apply) or *is* converted; in the latter case, the constraint of 6.1p2 is
violated and this sentence has no effect.
Delete 5.1.1.2p2, and replace it by a constraint at the end of 5.2.1
(forming a new paragraph 6):
Constraint
A universal-character-name shall not specify (in either form) a
character short identifier less than 00A0 other than the following:
0024 0040 0060
This is a more consistent position for the restriction, and it has the
useful side effect of making it clear what the UCNs of the basic character
set *are*.
Replace 5.2.1.2p1, first bullet, by:
- The basic character set shall be present and shall be encoded using
single-byte characters.
There is no longer a need to check for the shift states of comments,
string literals, and so on, because during translation phase 1 these will
have been converted to a stateless representation using UCNs. Therefore
replace 5.2.1.2p2 by:
If a source file does not consist of a valid sequence of multibyte
characters, the behavior is undefined.
In 6.1.2.5p2, 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).
The second sentence of 6.1.2p2 restricts UCNs in identifiers to those
listed in annex H. If some other UCN appears, it is unclear whether the
behavior is undefined, or whether the UCN is not part of the
identifier.
This is further complicated by the example in footnote 122. If the text
appeared in a source file, by translation phase 4 it would be processed
as:
#define THIS\u0024AND\u0024THAT(a,b) ((a)+(b))
and so the replacement list *does* begin with a character required by
subclause 5.2.1, and thus this is unambiguously a definition of the
object-like macro THIS. However, this completely wrecks the whole
point of 6.8p4 and FN122 (added in TC1).
Replace the second sentence of 6.1.2p2 with:
Only universal-character-names corresponding to the characters listed
in annex I are nondigits.[20]
and append to footnote 20:
Since 00A0 is not listed in annex I, but 00C0 is, the sequence of
characters a\u00C0b\u00A0 consists of two preprocessing tokens; the first
is an identifier made up of three nondigits.
(note also the correction to the annex cited).
Replace 6.8p4 by:
In the definition of an object-like macro, either the replacement
list shall be separated from the identifier by white space, or it shall
begin with one of the 26 graphic characters in the basic character set
other than ( _ or \ (and thus shall not begin with a
universal-character-name).[122]
WG14: Response Code: E
-----------------------------------------------------------------
Public Comment Number PC-UK0028
Comment 1.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 5.2.4.1
Title: clarify translation limit for identifiers using UCNs.
Detailed description:
In 5.2.4.1, change the relevant translation limits to:
- 63 significant initial characters in an internal identifier or a
macro name (a universal-character-name shall count as one)
- 31 significant initial characters in an external identifier (a
univeral-character-name shall count as 4 if less than 0000FFFF, and 8
otherwise)
or some other wording that reflects the Committee's intent if different.
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0029
Comment 1.
Category: [one of the following]
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 5.2.4.2.2
Title: clarify rounding to nearest
Detailed description:
In 5.2.4.2.2p5, change the third case:
1 to nearest
to:
1 to nearest (if the value to be rounded is exactly between two
representable values, it is unspecified which is chosen)
WG14: Response Code: CE
Draft is clear enough as is.
-----------------------------------------------------------------
Public Comment Number PC-UK0030
Comment 1.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 5.1.1.2
Title: Require UCNs to appear in translation phase 1
Detailed description:
Currently, a source file can contain:
\u12\
34
and it is unclear whether or not this is a universal character name. Add
to the end of 5.1.1.2 translation phase 2:
If a character sequence that matches the syntax of a
universal-character-name is produced by such splicing, the behavior is
undefined.
It is also unclear whether:
??/u1234
is a universal character name or not. I think the current wording allows
it, but a footnote would be a good idea.
WG14: Response Code: SD
See WG14 N837 UCN handling.
-----------------------------------------------------------------
Public Comment Number PC-UK0031
Comment 1.
Category: Normative change to existing feature retaining the original
intent
Committee Draft subsection: 7.3.1.9, 7.18.2.1.9
Title: make ispunct() true for basic punctuation characters
Detailed description:
There appears to be no character for which it is required that ispunct()
is true. This is surprising, to say the least, as one would expect that it
is true for characters like '.' and '('.
Replace 7.3.1.9p2 by EITHER:
The /ispunct/ function tests for any printing character for which
neither /isspace/ nor /isalnum/ is true.
OR:
The /ispunct/ function tests for any character that is one of the 29
graphic characters in the basic execution character set or is one of a
locale-specific set of printing characters for which neither
/isspace/ nor /isalnum/ is true. In the "C" locale it returns true only
for the characters in the basic execution character set.
[These two are not equivalent outside the "C" locale.]
WG14: Response Code: NC
-----------------------------------------------------------------
Public Comment Number PC-UK0032
Comment 1.
Category: Inconsistency
Committee Draft subsection: 6.1.2.1
Title: tidy-up specification of overlapping scopes
Detailed description:
The use of "non-overlapping" in 6.1.2.1p implies that the "scope" of an
identifier excludes any block where the identifier is redeclared. This is
inconsistent with the description of inner and outer scopes in paragraph
3; the latter is probably preferable.
Change the word "non-overlapping" in paragraph 1 to "different".
WG14: Response Code: EY
-----------------------------------------------------------------
Public Comment Number PC-UK0033
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.2.2
Title: Fix wording relating to "number of arguments"
Detailed description:
6.3.2.2p2 states "the number of arguments shall agree with the number of
parameters". This does not clearly take account of varargs functions.
Change the wording to:
the number of arguments shall equal or, if the prototype ends with an
ellipsis (, ...), shall be no less than, the number of parameters
(excluding any ellipsis).
WG14: Response Code: CE
-----------------------------------------------------------------
Public Comment Number PC-UK0034
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.3.2.3
Title: Adjust wording concerning qualifiers on structure members
Detailed description:
6.3.2.3p3 reads, in part:
If the first expression has qualified type, the result has the
so-qualified version of the type of the designated member.
This should read:
The result has all the qualifiers of the first expression and those
of the designated member.
Also add an example:
In:
struct s { int i; const int ci; };
struct s s;
const struct s cs;
volatile struct s vs;
the various members have the types:
s.i int
s.ci const int
cs.i const int
cs.ci const int
vs.i volatile int
vs.ci volatile const int
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0035
Comment 1.
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.3.2.4, 6.3.3.1
Title: Allow increment/decrement of complex objects.
Detailed description:
All the operators that can be applied to a real floating object can also
be applied to complex ones, with the sole exception of ++ and --. There is
no obvious reason for this exception (particularly since the ! operator
can be applied).
In 6.3.2.4p1 and 6.3.3.1p1, change "real" to "arithmetic".
WG14: Response Code: AN
Allowing ++ and -- to operate on complex values
is surprising in that similar operations on
imaginary values do not produce the same results.
-----------------------------------------------------------------
Public Comment Number PC-UK0036
Comment 1.
Category: Normative change where the intent is unclear
Committee Draft subsection: 6.3.16
Title: Define the result of the assignment operator
Detailed description:
6.3.16p3 states:
An assignment expression has the value of the left operand after the
assignment, but is not an lvalue.
It is not clear what this means when the left operand is a volatile
object that changes through external causes - it could mean the value
stored, or it could mean the result of reading the object.
Replace these words with the unambiguous:
The value of the assignment expression is the value stored in the
left operand, but is not an lvalue.
WG14: Response Code: NC
-----------------------------------------------------------------
Public Comment Number PC-UK0037
Comment 1.
Category: Inconsistency
Committee Draft subsection: 6.4
Title: Constant expression cannot contain the size of a VLA
Detailed description:
6.4 does not require a constraint for "sizeof(v)" where v has variable
length array type. FN83 also fails to notice this case.
Append to 6.4p3:
Any /sizeof/ operator shall have an operand whose size is defined to
be constant.
Move the reference to FN83 to the new end of the paragraph, and within
the footnote change:
not evaluated
to:
not evaluated when no component of the operand has variable length
array type
In 6.4p6 remove the words "sizeof expressions ... name of such a type".
WG14: Response Code: AL
-----------------------------------------------------------------
Public Comment Number PC-UK0038
Comment 1.
Category: Feature that should be removed
Committee Draft subsection: 6.1.8
Title: UCNs should not be permitted in preprocessing numbers
Detailed description:
The syntax in 6.1.8p1 uses "nondigit", which used to represent the 52
letters plus underscore but now also includes the UCNs in Annex I. I
believe this is a mistake, and the syntax should be adjusted
accordingly.
WG14: Response Code: N
The syntax is as intended; this is useful when using the ##
operator to create identifiers.
-----------------------------------------------------------------
Public Comment Number PC-UK0039
Comment 1.
Category: Feature that should be included
Committee Draft subsection: 6.1.3.1
Title: Allow 'i' suffix for floating constants
Detailed description:
It should be possible to write an imaginary floating point constant
rather than having to multiply by the macro /I/. Furthermore, this macro
is not available in a free-standing implementation.
The obvious way to do this is to allow the suffix 'i' or 'I'. To do so:
In 6.1.3.1p1:
- Remove "floating-suffix/opt" from the various alternatives to
"decimal-floating-constant" and
"hexadecimal-floating-constant".
- Append "floating-suffices/opt" to each alternative for
"floating-constant".
- Add:
floating-suffices:
floating-suffix imaginary-suffix
imaginary-suffix floating-suffix
imaginary-suffix: one of
i I
Append to 6.1.3.1p4:
If the constant has the suffix /i/ or /I/, then its type and value
are that resulting when the constant without that suffix is multiplied by
the value of the macro /I/ defined in the header <complex.h> and add a
forward reference to 7.8.
WG14: Response Code: AN
Freestanding implementations do not have to provide
complex types and an 'i' suffix introduces complex
values into the language in another way.
-----------------------------------------------------------------
Public Comment Number PC-UK0040
Comment 1.
Category: Normative change to intent of existing feature
Committee Draft subsection: 6.5.2.1
Title: Bitfields of non-standard types should require a diagnostic.
Detailed description:
If a bitfield is declared with a type other than plain, signed, or
unsigned int, the behavior is undefined. Since this can easily be
determined at compile time, it should generate a diagnostic. An exception
is required for the type underlying /bool/, and perhaps for any type that
can have valid bitfields.
Delete the first sentence of 6.5.2.1p8.
Add to the end of 6.5.2.1p3:
A bit-field shall have a type that is a qualified or unqualified
version of /signed int/ or /unsigned int/, or of the type /bool/ defined
in the header <stdbool.h>.
or:
A bit-field shall have a type that is a qualified or unqualified
version of /signed int/ or /unsigned int/, of the type /bool/ defined in
the header <stdbool.h>, or of some other implementation-defined integer
type.
WG14: Response Code: N
A diagnostic is not desired as this is a common extension.
-----------------------------------------------------------------
Public Comment Number PC-UK0041
Comment 1.
Category: Inconsistency
Committee Draft subsection: 6.5.2.2, 6.5.2.3
Title: An example uses an incomplete type in the wrong context
Detailed description:
6.5.2.3 example 3 uses the line:
enum f { c = sizeof (enum f) };
but 6.5.2.2p5 indicates that the type is not complete at the point it is
used in the constant expression, and so a constraint is violated. The
example must be reworded or deleted.
WG14: Response Code: EY
-----------------------------------------------------------------
Public Comment Number PC-UK0042
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.4
Title: Clarify some aspects of inline
Detailed description:
In 6.5.4p6, add a footnote referenced at the end of the paragraph:
[*] The call need not be due to the direct appearance of the name of
the function at the point of calling; it may be through some kind of
indirection.
In 6.5.4p8, after:
because /fahr/ is also declared with /extern/
add:
(even though that declaration is not visible at the definition of
/fahr/)
WG14: Response Code: CE
-----------------------------------------------------------------
Public Comment Number PC-UK0044
Comment 1.
Category: Inconsistency
Committee Draft subsection: 6.5.7
Title: Removal of implicit int - further lacunae
Detailed description:
In 6.5.7p3, the last sentence:
If the identifier is redeclared in an inner scope or is declared as a
member of a structure or union in the same or an inner scope, the type
specifiers shall not be omitted in the inner declaration.
are no longer needed, as the type specifiers cannot be omitted.
WG14: Response Code: E
-----------------------------------------------------------------
Public Comment Number PC-UK0046
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 6.5.7
Title: Correct ranges of bitfields in an example
Detailed description:
In 6.5.7 example 3, change the specified ranges:
- from "at least the range [-15, +15]" to "either the range [-15, +15] or
the range [-16, 15]
- from "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]"
WG14: Response Code: CE
-----------------------------------------------------------------
Public Comment Number PC-UK0047
Comment 1.
Category: Request for information/clarification
Committee Draft subsection: 6.8
Title: Handling of unknown preprocessing directives
Detailed description:
In the preprocessing phase (translation phase 4), consider the line:
# unknown command
It is unclear whether or not this requires a diagnostic. Presumably the #
punctuator will remain until translation phase 7 where it cannot fit in
the syntax, but even if so, this is less than clear. However, this is easy
to fix. In the syntax in 6.8p1, change group-part to:
group-part:
non-directive new-line
if-section
control-line
and add:
non-directive:
pp-tokens/opt
Then add a constraints clause:
Constraint
The first preprocessing-token (if any) in a non-directive shall not
be /#/.
Finally, delete 6.8.3p8, because this can no longer occur.
WG14: Response Code: CE
-----------------------------------------------------------------
Public Comment Number PC-UK0048
Comment 1.
? Category: Other: unresolved issue
Committee Draft subsection: 6.1.7, 6.8.2
Title: Problems with UCNs in header file names
Detailed description:
Consider the line:
#include "a$b.h"
This will be changed, in translation phase 1, to:
#include "a\u0024b.h"
Both of these involve undefined behavior, but equally both are valid file
names on at least one common operating system. It is likely that
implementations that implement UCNs in a natural manner are going to have
problems deciding which of the names was intended.
I'm not clear what the answer is, but it needs addressing.
WG14: Response Code: SD
See WG14 N837 UCN Handling. UCN's are not longer
converted in phase I.
-----------------------------------------------------------------
Public Comment Number PC-UK0049
Comment 1.
Category: Request for information/clarification
Committee Draft subsection: 6.8.1
Title: Handling of UCNs in character constants in #if directives
Detailed description:
Consider the line:
#if '\u0024' < 100
where dollar is in the single-byte execution character set. It is not
completely clear from 6.8.1p3 that the UCN is converted to a single
character, since this normally happens in translation phase 5.
In 6.8.1p3, last two lines of page 157 (postscript version), change:
... which may involve converting escape sequences into execution
character set members. Whether
to:
... which may involve converting source character set members, escape
sequences, and universal character names into execution character set
members in the manner of translation phase 5. However,
whether ...
WG14: Response Code: SD
Please see WG14 N837 UCN handling.
-----------------------------------------------------------------
Public Comment Number PC-UK0050
Comment 1.
Category: Inconsistency
Committee Draft subsection: 6.1.2.8.1, 6.3.2.3
Title: Effects on other members of assigning to a union member
Detailed description:
6.3.2.3p5 has wording concerning the storing of values into a union
member:
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.
The requirement to be implementation-defined means that an implementation
must ensure that all stored values are not trap representations in the
types of other members, and thus, in effect, eliminates the possibility of
trap representations at all.
It turns out that the wording of 6.1.2.8.1 is sufficient to explain the
behavior in these circumstances, and the cited wording in 6.3.2.3 merely
muddles the issue. It should be removed; the rest of the paragraph can
stand alone.
WG14: Response Code: M
The implementation-defined behavior does not prohibit trap
representations.
-----------------------------------------------------------------
Public Comment Number PC-UK0051
Comment 1.
Category: Inconsistency
Committee Draft subsection: 7.1.7
Title: true and false are not reserved identifiers
Detailed description:
7.1.7p3 defines "true" and "false" as macros, which thus a reserves them
in accordance with the third bullet of 7.1.3. FN138 suggests that an
implementation could use these names as enumeration constants, but they
are not reserved in that context. That is:
#include <stdbool.h>
#undef true;
complex long double true;
is strictly conforming.
Since the implementation in the footnote is a useful one (for the reasons
given), 7.1.7 should reserve these names at file scope, either explicitly
or by changing these two identifiers to be "const int"
(though of course this would give them an address).
WG14: Response Code: SD
-----------------------------------------------------------------
Public Comment Number PC-UK0052
Comment 1.
Category: Feature that should be included
Committee Draft subsection: 6.8.3
Title: Add a __VA_COUNT__ facility for varargs macros
Detailed description:
Unlike with function calls, it is trivial for an implementation to
determine the number of arguments that match the ... in a varargs macro.
There are a number of useful things that can be done with this (at the
least, providing argument counts to varargs functions). Therefore this
information should be made available to the macro expansion.
In 6.8.3p5, change
The identifier /__VA_ARGS__/ ...
to:
The identifiers /__VA_ARGS__/ and /__VA_COUNT__/ ...
Append to 6.8.3.1p2:
The identifier /__VA_COUNT__/ that occurs in the replacement list
shall be treated as if it were a parameter; it is replaced by a single
token which is the number of trailing arguments (as a decimal constant)
that were merged to form the variable arguments.
WG14: Response Code: NC
-----------------------------------------------------------------
Public Comment Number PC-UK0053
Comment 1.
Category: Feature that should be included
Committee Draft subsection: 7.4
Title: Require consistency if an implementation adds to <inttypes.h>
Detailed description:
7.20.3 reserves all names such as int11_t and uint_least22_t. This allows
implementations to define them in <inttypes.h>, but does not require these
names to be handled consistently. Adding such a requirement would aid
portability. This proposal does not require any types other than those
already required by the header.
[The following is a minimal change. If requested, I can rewrite the header
to integrate the changes
better.]
Append to 7.4 as a new paragraph 5:
For each typedef name listed as /optional/ and which can be defined
as a type existing in the implementation, it is unspecified whether or not
the type is defined, but if it is provided, so shall the corresponding
limit and /fprintf/ macros (as with all the types in this header, the
/fscanf/ macros are optional).
Append to 7.4.1.1, 7.4.1.2, and 7.4.1.3 as a new paragraph 4:
Any other typedef name of these two forms is an optional type.
Append to 7.4.2 as a new paragraph 3:
Any optional types shall have /MAX/ and, if signed, /MIN/ macros with
the appropriate name and value as if explicitly included in the following
subclauses. For example, if the type /uint14_t/ is provided, then the
macro UINT14_MAX shall be provided with value exactly 16383.
Append to 7.4.4p1:
Any optional types shall have /fprintf/ and /fscanf/ macros with the
appropriate name and value as if explicitly included in the following
lists. For example, if the type /uint14_t/ is provided, then the
macros /PRIo14/, /PRIu14/, /PRIx14/, /PRIX14/, /SCNo14/, /SCNu14/, and
/SCNx14/ should be added to the lists below.
WG14: Response Code: NC
-----------------------------------------------------------------
Public Comment Number PC-UK0054
Comment 1.
Category: Other: C++ conflict avoidance
Committee Draft subsection: 6.8.8
Title: Require that __cplusplus not be defined
Detailed description:
Add to 6.8.8 a new paragraph 5:
The implementation shall not predefine the macro /__cplusplus/, nor shall
it define this macro in any header defined in clause 7.
WG14: Response Code: II
-----------------------------------------------------------------
Public Comment Number PC-UK0055
Comment 1.
Category: Editorial change/non-normative contribution
Committee Draft subsection: 7.8
Title: It should be explicitly possible to redefine I
Detailed description:
7.8p3 should end:
Not withstanding the provisions of subclause 7.1.3, it is permitted
to undefine and redefine the macro I.
This was clearly the intent.
WG14: Response Code: AL
It is now possible to redefine the "I" macro.
-----------------------------------------------------------------
Public Comment Number PC-UK0056
Comment 1.
Category: Feature that should be included
Committee Draft subsection: 7.1.6
Title: Add a symbol giving the maximum alignment
Detailed description:
[I eventually decided <stddef.h> is the right place for this.]
Add a new macro to <stddef.h>:
_ALIGNMENT_ALL
which expands to an integer constant expression that has type
/size_t/, the value of which is the least common multiple of the
alignments of all object types.[*]
[*] If /p/ has pointer to character type and is suitably aligned for
some type /t/, then /(p + _ALIGNMENT_ALL)/ is also suitably aligned for
the same type /t/, no matter what /t/ is.
Possibly also add the macros:
_ALIGNMENT_INTS
_ALIGNMENT_FLOATS
_ALIGNMENT_POINTERS
which are the least common multiples of the alignments for integer types,
for floating types, and for pointer types respectively. Other names could
also be conceived of (_ALIGNMENT_STRUCTS, _ALIGNMENT_UNIONS,
_ALIGNMENT_SCALARS, etc.).
WG14: Response Code: NC
-----------------------------------------------------------------
Public Comment Number PC-UK0057
Comment 1.
Category: Normative change to intent of existing feature
Committee Draft subsection: 7.13.2, 7.13.3, 7.19.3.10, 7.19.7
Title: Better locale handling for wide oriented streams
Detailed description:
7.13.2p6 associates an /mbstate_t/ object with each stream, and
7.13.3p11-13 state that this is used with the various wide-oriented
functions. On the other hand, 7.19.7p3 places very strict restrictions on
the use of such objects, restrictions that cannot be met through the
functions provided in the Standard while allowing convenient use of wide
formatted I/O.
Furthermore, an /mbstate_t/ object is tied to a single locale based on
the first time it is used. This means that a wide oriented stream is tied
to the locale in use the first time it is read or written. This will be
surprising to many users of the Standard.
Therefore, at the very least these objects should be exempt from the
restrictions of 7.19.7; the restrictions of 7.13 (for example, 7.13.2p5
bullet 2) are sufficient to prevent unreasonable behaviour. In addition,
the locale of the object should be tied and not affected by the current
locale. The most sensible way to do this is to use the locale in effect
when the file is opened, but allow /fwide/ to override this.
In 7.13.2p6, add after the first sentence:
This object is not subj