ISO/
IEC
JTC1/SC22/WG14
N762
Minor Changes to C9x
September 26, 1997 Document No. WG14/N762 (J11/97-126)
Douglas A. Gwyn
US Army Research Laboratory
Adelphi, MD
ABSTRACT
While looking things up in C9x Draft 10, I found
several places where small improvements were
needed. Some of these could be considered
editorial, but others are clearly substantive.
Most of the ideas for substantive changes arose in
the course of editorial work on already-approved
proposals.
Because we are trying to complete the C9x document
as soon as possible, I propose only changes that
can be quickly and easily made as part of the
ongoing editing process. My intention is that the
Menlo Park agenda include a session wherein each
item would be briefly presented, questions would
be answered, and a quick yes/no vote would be
taken for each proposed change. (If any item were
to require extended debate, then I would simply
withdraw that proposal.)
1. keywords cannot be identifiers
1.1 the_problem
There is a Constraint in 6.1.2 Identifiers that says:
In translation phases 7 and 8, an identifier shall not
consist of the same sequence of characters as a
keyword.
This injunction is already given in the preceding 6.1.1
Keywords, Semantics, and I'm not sure that there is a
reliable way to diagnose all violations.
1.2 my_proposal
I suggest any of three alternatives:
1.2.1 Change the Constraints given in 6.1.2 Identifiers to
a footnote.
1
Document No. WG14/N762 (J11/97-126)inor Changes to C9x September 26, 1997
1.2.2 Move the Constraints given in 6.1.2 Identifiers to
the Description section of the same subclause.
1.2.3 Delete the Constraints given in 6.1.2 Identifiers.
2. pure binary numeration system
2.1 the_problem
The requirement that integer types be represented using a
``pure binary numeration system'' has important
ramifications; however, the explanation of this phrase is
delegated to a footnote, leading many readers of the
Standard to believe that it is not normative.
2.2 my_proposal
Move the text of Footnote 25 from 6.1.2.5 Types to clause 3
Definitions and conventions (new subclause 3.16+ Pure binary
numeration system), and delete the footnote reference mark
``25''.
3. string literal confusion
3.1 the_problem
In the course of figuring out whether the requirement in
6.5.7 Initialization, Constraints that each expression in an
initializer list for certain objects be a constant
expression properly allows for the use of string literals to
initialize character arrays, I discovered some sloppiness in
the use of the term ``string literal''. (Incidentally, the
answer to the above question is ``yes'', although it depends
on some accidents working out right.) 6.1.4 String literals
says that ``A character string literal is a sequence of zero
or more multibyte characters enclosed in double-quotes'',
and similarly for wide string literals. However, for the
logic of 6.5.7 Initialization to work out right, ``string
literal'' really needs to designate the resulting object
after translation phase 7. The Example in 6.1.4 String
literals is also phrased in such a way as to indicate this.
(The Example is incorrect in stating that there are two
characters contained in the resulting string literal; there
are actually three, including the terminating null byte.)
2
September 26, 1997 Minor Changes to C9xocument No. WG14/N762 (J11/97-126)
3.2 discussion
It is tricky to fix any of this without breaking things.
Therefore I propose a very slight tweak to the existing
wording.
3.3 my_proposal
In 6.1.4 String literals, Description, change the first
sentence from
A character string literal is a sequence of zero or
more multibyte characters enclosed in double-quotes, as
in "xyz".
to
A character string literal is designated by a sequence
of zero or more multibyte characters enclosed in
double-quotes, as in "xyz".
In 6.1.4 String literals, Examples, change
produces a single character string literal containing
the two characters whose values are '\x12' and '3',
to
produces a single character string literal containing
the three characters whose values are '\x12', '3', and
0,
4. strange characters in example
4.1 the_problem
One of the Examples at the end of 6.1.7, which doesn't
belong in this subclause anyway, uses characters that are
not in the basic source character set, rendering the example
not strictly conforming.
4.2 my_proposal
In 6.1.7 Header names, Examples, delete the two lines:
#define const.member@$
and
{#}{define} {const}{.}{member}{@}{$}
5. errors in example comments
3
Document No. WG14/N762 (J11/97-126)inor Changes to C9x September 26, 1997
5.1 the_problem
A few typographic errors crept into the Examples in 6.1.9
Comments.
Also, the four-character constant is unnecessary and perhaps
even unwise, since it is not strictly conforming code, and
the four-character string literal illustrates the same
point.
5.2 my_proposal
Replace 6.1.9 Comments, Examples content with the following:
"a//b" // four-character string literal
#include "//e" // undefined behavior
// */ // comment, not syntax error
f = g/**//h; // equivalent to f = g / h;
//\
i(); // part of two-line comment
/\
/ j(); // part of two-line comment
#define glue(x,y) x##y
glue(/,/) k(); // syntax error, not comment
/*//*/ l(); // equivalent to l();
m = n//**/o
+ p; // equivalent to m = n + p;
6. pointer <lt;lt;lt;--> integer conversion
6.1 the_problem
Apparently DR #57 said that there doesn't have to exist an
integer type suitable for holding any object pointer, but
the wording in the C9x draft about this, which has not
changed since C89, can easily be read as stating the
opposite.
A second problem is that the current wording requires the
implementation to define the meaning for every conversion of
an arbitrary integer value to a pointer, which seems to
impose an unnecessarily heavy burden on some
implementations.
6.2 my_intention
I agree that it is best not to require that implementations
provide such a type; also that it can be useful for
implementations to support such conversions. Because the
current wording does not guarantee that the type must exist,
and the ``requirement'' occurs in a Semantics section, I
4
September 26, 1997 Minor Changes to C9xocument No. WG14/N762 (J11/97-126)
believe that the following change would not affect any
implementation or program, but it would more clearly
indicate the nature of such a facility. (It could make
implementation conformance easier in some cases.)
6.3 my_proposal
Remove the following words from 6.3.4 Cast operators,
Semantics:
A pointer may be converted to an integer type. The
size of integer required and the result are
implementation-defined. If the space provided is not
long enough, the behavior is undefined.
An arbitrary integer may be converted to a pointer.
The result is implementation-defined.58
along with Footnote 58.
In I.5 Common extensions, add a new subclause I.5.6+
Conversion between pointers and integers:
A pointer may be converted to some integer type, and
some integers may be converted to pointers. Details of
these conversions are implementation-defined. (6.3.4)
7. trailing comma on enumerator list
7.1 the_problem
Many people, including Ken Thompson, responded unfavorably
to C89's requirement that a trailing comma after an
enumerator list must be diagnosed, contrary to previous
widespread existing practice. This requirement is
inconsistent with C89's treatment of trailing comma after an
initializer list (it's optional there), and it complicates
programs that generate C source code.
7.2 my_proposal
In 6.5.2.2 Enumeration specifiers, Syntax, add another
derivation rule to the grammar for
enum-specifier:
enum identifieropt { enumerator-list , }
Also make the corresponding change in B.2.2 Declarations.
5
Document No. WG14/N762 (J11/97-126)inor Changes to C9x September 26, 1997
8. erroneous footnote 82
8.1 the_problem
Footnote 82 erroneously says that only through the use of
typedefs can array or function type specifications include
any type qualifiers.
8.2 my_opinion
I think this footnote was trying to be helpful, but
incorrect footnotes are not helpful.
8.3 my_proposal
In 6.5.3 Type qualifiers, delete Footnote 82 and the
reference to it.
9. typedefs don't define
9.1 the_problem
Some people have found the terminology of 6.5.6 Type
definitions misleading.
9.2 my_proposal
Change the name to 6.5.6 Typedefs, and in the first sentence
of Semantics change
each declarator defines
to
each declarator declares
10. _Pragma missing from grammar
10.1 the_problem
There ought to be a derivation rule involving the new
_Pragma operator.
10.2 my_proposal
In 6.8 Preprocessing directives, Syntax, add another
derivation rule for
control-line:
_Pragma ( string-literal )
6
September 26, 1997 Minor Changes to C9xocument No. WG14/N762 (J11/97-126)
11. misplaced macro-replacement constraint
11.1 the_problem
The last Constraint in 6.8.1 Conditional inclusion has
nothing to do with conditional inclusion.
11.2 my_proposal
Move the last paragraph from 6.8.1 Conditional inclusion,
Constraints:
Each preprocessing token that remains after all macro
replacements have occurred shall be in the lexical form
of a token.
to a new Constraints section at the beginning of 6.8.3.4
Rescanning and further replacement, and follow this with the
(previously implicit) section heading Semantics.
12. replacement of object-like macro identifier
12.1 the_problem
The macro replacement semantics incorrectly include among
identifiers that are replaced by macro expansion those that
are used as macro names in various preprocessing directives.
12.2 my_proposal
In 6.8.3 Macro replacement, Semantics, change
defines an object-like macro that causes each
subsequent instance of the macro name106
to
defines an object-like macro that causes each
subsequent instance of the macro name106, except for
the identifier in another #define, #undef, #ifdef, or
#ifndef directive or as the operand of a defined
operator,
13. type qualifiers in standard headers
13.1 the_problem
An implementation may declare typedef names as qualified
types in the standard headers. This can cause unpleasant
surprises.
7
Document No. WG14/N762 (J11/97-126)inor Changes to C9x September 26, 1997
13.2 note
This is not just nit-picking; I have heard that at least one
implementation already includes volatile in its declaration
of sig_atomic_t.
13.3 my_proposal
I actually have two alternative formulations, depending on
whether there is a consensus that some standard typedef
names (e.g., sig_atomic_t) ought to be allowed to be
declared as qualified types.
13.3.1 At the end of 7.1.2 Standard headers add a new
paragraph:
Declarations of types described in this clause shall
not include type qualifiers.
13.3.2 At the end of 7.1.2 Standard headers add a new
paragraph:
Declarations of types described in this clause shall
not include type qualifiers, unless explicitly stated
otherwise.
13.3.2.1 If it is decided that a contrary type is
sig_atomic_t, then also in 7.10 Signal handling <signal.h>
change
which is the integer type of an object
to
which is the (possibly volatile-qualified) integer type
of an object
14. math error conditions misplaced
14.1 the_problem
Subclause 7.7.3 Treatment of error conditions is embedded in
the middle of functional descriptions, instead of being near
the front of the <math.h> subclause, which would be more in
line with the general style of the Standard.
14.2 my_proposal
Move the entire subclause (including heading, with automatic
renumbering) 7.7.3 Treatment of error conditions in front of
7.7.1 The FP_CONTRACT pragma.
8
September 26, 1997 Minor Changes to C9xocument No. WG14/N762 (J11/97-126)
15. missing words for lgamma
15.1 the_problem
The lgamma Returns specification is inaccurate.
15.2 my_proposal
In 7.7.8.4 The lgamma function, Returns, change ``gamma'' to
``gamma of x''.
16. race condition in signal handler
16.1 the_problem
The C89 condition that a signal handler upon entry can have
SIG_DFL established for the signal (which forces an unsafe
timing window for asynchronous signals) is a hold-over from
pre-POSIX days that encourages programmers to use less-
standard signal mechanisms. (I argued for this
specification originally, on the grounds of backward
compatibility.)
A second, related problem is that too little is said about
the implementation-defined blocking, making it difficult to
write useful portable programs using signal.
16.2 my_intention
The C89 alternative, implementation-defined blocking of the
signal, should now be required. Just enough additional
requirements should be imposed to guarantee a reasonable way
to safely write portable programs that catch asynchronous
signals such as SIGINT. I believe my proposal for the
latter is compatible with current implementations of signal
blocking, but I would appreciate feedback on this matter.
16.3 my_proposal
I propose two independent changes that can be decided
separately:
16.3.1 In 7.10.1.1 The signal function, Description, second
paragraph, change
When a signal occurs, if func points to a function,
first the equivalent of signal(sig, SIG_DFL); is
executed or an implementation-defined blocking of the
signal is performed. (If the value of sig is SIGILL,
whether the reset to SIG_DFL occurs is implementation-
defined.)
9
Document No. WG14/N762 (J11/97-126)inor Changes to C9x September 26, 1997
to
When a signal occurs, if func points to a function,
first an implementation-defined blocking of the signal
is performed.
16.3.2 After the third paragraph in 7.10.1.1 The signal
function, Description, add a new paragraph:
While a signal is blocked, a call to the signal
function with sig equal to that signal number shall
cause the signal to be unblocked.
Also, append to the fourth paragraph (concerning program
startup) in 7.10.1.1 The signal function, Description:
Some signals may be blocked upon program startup.
17. more signal returns undefined
17.1 the_problem
Returning from a signal handler for SIGILL or SIGSEGV ought
to explicitly cause undefined behavior (because that's what
happens in actuality).
17.2 my_proposal
In 7.10.1.1 The signal function, Description, second
paragraph, change
and the value of sig was SIGFPE
to
and the value of sig was SIGFPE, SIGILL, SIGSEGV,
18. functions in signal handler
18.1 the_problem
The words ``the signal function itself'' might be confusing,
since ``itself'' more properly refers to the signal handler.
18.2 my_solution
In 7.10.1.1 The signal function, Description, third
paragraph, change
other than the signal function itself
to
other than the signal function
10
September 26, 1997 Minor Changes to C9xocument No. WG14/N762 (J11/97-126)
19. opening text file in update mode
19.1 the_problem
The draft says,
Opening (or creating) a text file with update mode may
instead open (or create) a binary stream in some
implementations.
This doesn't seem like a specification so much as a warning.
Since an attempt to open a file inappropriately is allowed
to fail, it is much better in such a situation for fopen to
report failure than to secretly shift the mode of the stream
(which could invalidate further processing).
19.2 my_proposal
In 7.12.5.3 The fopen function, Description, delete that
sentence:
Opening (or creating) a text file with update mode may
instead open (or create) a binary stream in some
implementations.
20. common fprintf extension
20.1 the_problem
There is no good reason to disallow %lf in fprintf format
strings. It makes sense, improves compatibility with fscanf
format strings, and is commonly implemented as a conforming
extension. Also, %d vs. %hd is supported, which makes no
more or less sense than %lf vs. %f.
20.2 comment
I suspect that one reason this was left out was the
difficulty in fitting it into the wording pattern of the
existing text.
20.3 my_proposal
In 7.12.6.1 The fprintf function, Description, before
or an optional L specifying
insert the following:
an optional l followed by an a, A, e, E, f, F, g, or G
conversion specifier (the l has no effect);
In 7.18.1.1 The fwprintf function, Description, before
or an optional L specifying
insert the following:
an optional l followed by an a, A, e, E, f, F, g, or G
11
Document No. WG14/N762 (J11/97-126)inor Changes to C9x September 26, 1997
conversion specifier (the l has no effect);
21. errors in fscanf spec
21.1 the_problem
fscanf's %i, %d, and %n are said to have arguments that are
merely pointers to integer; that should be signed integer.
Also, the undefined term ``valid'' is used, whereas the
fprintf specification contains better wording that could be
adopted for fscanf.
There is also a misleading ``which'' where the restrictive
``that'' is needed.
21.2 my_proposal
The following three items can be decided separately.
21.2.1 In 7.12.6.2 The fscanf function, Description, in the
paragraph beginning ``An input item is read from the
stream,'' change
the longest sequence of input characters which does not
exceed
to
the longest sequence of input characters that does not
exceed
In 7.18.2.2 The fwscanf function, Description, in the
paragraph beginning ``An input item is read from the
stream,'' change
the longest sequence of input wide characters which
does not exceed
to
the longest sequence of input wide characters that does
not exceed
21.2.2 In 7.12.6.2 The fscanf function, Description, change
The following conversion specifiers are valid:
to
The conversion specifiers and their meanings are:
In 7.18.2.2 The fwscanf function, Description, change
The following conversion specifiers are valid:
to
The conversion specifiers and their meanings are:
12
September 26, 1997 Minor Changes to C9xocument No. WG14/N762 (J11/97-126)
21.2.3 In 7.12.6.2 The fscanf function, Description, under
each of the conversion specifiers d, i, and n, change
shall be a pointer to integer
to
shall be a pointer to signed integer
In 7.18.2.2 The fwscanf function, Description, under each of
the conversion specifiers d, i, and n, change
shall be a pointer to integer
to
shall be a pointer to signed integer
22. numeric conversion for char type
22.1 the_problem
The lack of a numeric conversion specification in fscanf for
char data analogous to %hd for short, %d for int, %ld for
long, and %lld for long long became quite apparent while I
was attempting to update the <inttypes.h> specification
(Document WG14/N761). Such a format conversion could be
quite useful in reading Boolean values, for example.
There are also a couple of errors associated with the
addition of wording for ll.
22.2 discussion
The only reason I can see for this omission is historical
inertia.
To maintain maximum parallelism between fprintf and fscanf,
we ought to add the facility to both families rather than
just to fscanf.
I intentionally don't try to cover wchar_t data, because
that's not one of the basic standard integer types.
22.3 my_proposal
I suggest two alternatives for how to spell the conversion
modifier, hh or H. Here I show just the hh alternative
(which is the one I prefer); it would be easy enough to edit
this to use another spelling.
22.3.1 In 7.12.6.1 The fprintf function, Description,
change
- An optional h specifying that a following d,
to
13
Document No. WG14/N762 (J11/97-126)inor Changes to C9x September 26, 1997
- An optional hh specifying that a following d, i,
o, u, x, or X conversion specifier applies to a
signed char or unsigned char argument (the
argument will have been promoted according to the
integral promotions, and its value shall be
converted to signed char or unsigned char before
printing); an optional h specifying that a
following d,
In the same paragraph, change
If an h, l, or L appears with any other
to
If an hh, h, l, ll, or L appears with any other
In 7.12.6.2 The fscanf function, Description, change
- An optional h, l (ell), or ll (ell-ell), or L
to
- An optional hh, h, l (ell), ll (ell-ell), or L
In the same paragraph, change
d, i, and n shall be preceded by h if the corresponding
argument is a pointer to short int rather than a
pointer to int,
to
d, i, and n shall be preceded by hh if the
corresponding argument is a pointer to char rather than
a pointer to int, by h if it is a pointer to short int,
In the same paragraph, change
o, u, and x shall be preceded by h if the corresponding
argument is a pointer to unsigned short int rather than
a pointer to unsigned int,
to
o, u, and x shall be preceded by hh if the
corresponding argument is a pointer to unsigned char
rather than a pointer to unsigned int, by h if it is a
pointer to unsigned short int,
In the same paragraph, change
If an h, l, or L appears with any other
to
If an hh, h, l, ll, or L appears with any other
In 7.18.2.1 The fwprintf function, Description, change
- an optional h specifying that a following d,
to
14
September 26, 1997 Minor Changes to C9xocument No. WG14/N762 (J11/97-126)
- an optional hh specifying that a following d, i,
o, u, x, or X conversion specifier applies to a
signed char or unsigned char argument (the
argument will have been promoted according to the
integral promotions, and its value shall be
converted to signed char or unsigned char before
printing); an optional h specifying that a
following d,
In the same paragraph, change
If an h, l, ll, or L appears with any other
to
If an hh, h, l, ll, or L appears with any other
In 7.18.2.2 The fwscanf function, Description, change
- An optional h, l (ell), ll (ell-ell), or L
to
- An optional hh, h, l (ell), ll (ell-ell), or L
In the same paragraph, change
d, i, and n shall be preceded by h if the corresponding
argument is a pointer to short int rather than a
pointer to int,
to
d, i, and n shall be preceded by hh if the
corresponding argument is a pointer to char rather than
a pointer to int, by h if it is a pointer to short int,
In the same paragraph, change
o, u, and x shall be preceded by h if the corresponding
argument is a pointer to unsigned short int rather than
a pointer to unsigned int,
to
o, u, and x shall be preceded by hh if the
corresponding argument is a pointer to unsigned char
rather than a pointer to unsigned int, by h if it is a
pointer to unsigned short int,
In the same paragraph, change
If an h, l, ll, or L appears with any other
to
If an hh, h, l, ll, or L appears with any other
15
Document No. WG14/N762 (J11/97-126)inor Changes to C9x September 26, 1997
23. seek on same file okay
23.1 the_problem
Seek offsets are required to be obtained from the same
stream, not just from the same file. That means one can't
close a file and later reopen it and seek back into it.
23.2 discussion
It is possible that some operating system really imposes
this limitation, but I don't recall any like that. My guess
is that this was just imprecise wording that was never
noticed.
In the following, I rely on the vagueness of the phrase
``the same file'' to handle cases such as when a file is
somehow modified between the time of the tell and the seek;
this technicality (and a few similar complications) should
have been dealt with even in the previous formulation.
23.3 my_proposal
In 7.12.10.2 The fseek function, Description, change
an earlier successful call to the ftell function on the
same stream
to
an earlier successful call to the ftell function on a
stream associated with the same file
In 7.12.10.3 The fsetpos function, Description, change
an earlier successful call to the fgetpos function on
the same stream.
to
an earlier successful call to the fgetpos function on a
stream associated with the same file.
24. use of an unfamiliar term
24.1 the_problem
In the specification for strtod, what is a ``binary-exponent
part''?
24.2 my_proposal
In 7.13.1.5 The strtod function, Description, change
then an optional binary-exponent part,
to
then an optional binary-exponent part as defined in
16
September 26, 1997 Minor Changes to C9xocument No. WG14/N762 (J11/97-126)
6.1.3.1,
25. missing reference to C89
25.1 the_problem
Shouldn't there be a reference to our other base document,
the previous C standard?
25.2 my_proposal
In Annex A Bibliography, add the reference:
1. ISO/IEC 9899:1990, Programming Languages - C.
26. missing restrict in Annex B
26.1 the_problem
restrict is missing from the grammar in Annex B.
26.2 my_proposal
In B.2.2 Declarations, add under
(6.5.3) type-qualifier:
restrict
17