ANSI C -- miscellaneous suggestions

[Martin Minow]

This is one of a collection of comments on the Draft Standard, posted to
comp.lang.c for discussion before I mail a final draft to the Ansi C
committee.  Each message discusses one problem I have found with the Draft
Standard that I feel warrants a "no" vote.  Note that this message is my
personal opinion, and does not reflect on the opinions of my employer.

This message lists concerns -- these are questions or problems,
but are not sufficiently serious as to preclude my acceptance of
the standard.

----

Page 1, line 14.  The standard should specify the total list of words
reserved to the compiler and its libraries.

Page 6, line 40ff.  It is unclear whether the main() function may be
declared or invoked with more than 2 parameters.  One common extension
is to invoke main with a third parameter which specifies a list of
"environment variables."

Page 7, line 12.  Must the string in argv[0] be modifiable?

Page 10, 27.  The horizontal tab, vertical tab, and form feed characters
are not needed by the language.  The standard should declare that
horizontal tab is identical to space except in character and string
literals, and vertical tab and form feed are everywhere identical to newline.

Page 11, lines 29ff.  The standard should specify the internal representations
for the predefined escape sequences for implementations that use the
USASCII or Latin 1 alphabets, 

Page 12, line 29.  The minimum significance for external identifiers
should be changed to ``6 significant monocase initial characters in
an external identifier.''

Page 14, line 20ff.  FLT should be FLOAT. DBL should be DOUBLE. etc.  As
the first 31 characters of macro definitions are significant, there is no
need to sacrifice legibility (and maintainability) for consiseness.

Page 26, line 13.  The exceptions (the characters that may not appear
in string literals) should include the vertical tab character
and the form feed character, as these are equivalent to newlines.

Page 74, line 28.  Horizontal tab does not have an independent existance
during preprocessing.  The example should note that comments may preceed
or follow the # that introduces a preprocessing directive.

Page 75, line 36.  An arithmetic error in an #if expression (such as divide
by zero) shall result in a diagnostic error message.  However, a sequence
such as:

    #if (foo == 0) ? 0 : (10 / foo)

should not result in a diagnostic error message for any value of foo.

Page 82, line 24ff.  I would recommend the following clarifications to
the definition of the predefined macro names:

   __LINE__	The line number shall be as defined in section 3.8.4,
		page 81, line 30.

   __FILE__	There is no presumption that this string can be used to
		open a file during execution of the program.

   __DATE__	Neither this value nor the value of __TIME__ change during
		compilation.

A predefined name should be redefinable (by #undef). (The identifier
"defined" may not be redefined.)

Page 83, line 15ff.  Function prototypes with separate parameter identifier
and declaration lists offer a better environment for documentation than
the more concise function prototype format.  I would strongly recommend
that they not be marked obsolescent.

Page 85, line 35.  The ability to redefine any function declared in
a header as a macro may break existing programs that write, e.g.,

    #include <stdlib.h>
    extern long rand();

If rand() is declared as a macro, 

Page 89, line 13 (footnote 64):  The Standard should note that, in an
implementation that uses the Latin 1 character set, the printing
characters are those whose values lie from 0x20 through 0x7E or from
0xA0 through 0xFF. Control characters are those whose values lie from
0x00 through 0x1F, 0x7F, or from 0x80 through 0x9F.  The ranges for the other
<ctype.h> macros should be similarly extended.

Page 91, line 46ff. Note that, in a Latin 1 environment, the ispunct() and
isspace() functions should test for the non-breaking space at 0xA0.

Page 102, line 46ff. If longjmp() is called from a signal handler, volatile
objects may have indeterminate values as they cannot always be updated by
atomic (one machine cycle) operations. It is unrealistic to require an
implementation to lock interrupts before modifying a volatile object.  The
Standard should note that volatile objects are indeterminate when longjmp()
is called from an interrupt or signal handler.

Page 128, line 7.  Is one character of pushback guaranteed even before
anything has been read from the stream or after end of file or error?
The standard should be clarified on this point. (I don't care either way,
but would prefer permitting one character pushback at any time.)

Page 140, line 21ff. Predefined values for "successful termination"
and "unsuccessful termination" (argumemts to exit()) should be provided.

Page 142, line 16ff. An unsigned division function analogous to
div() would be useful.

----

Martin Minow
decvax!minow