osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/06/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Mon, 24 Jun 85 Volume 7 : Issue 4
Today's Topics:
Section A.7 (Compliance)
Section B.2.2 (alert character)
Section C.1.3.2 (integer suffix)
Section C.1.7 (comments)
Section C.3 (grouping of operations)
Section C.3.3.4 (sizeof)
Section C.5.2 type-specifier
Section C.8 (preprocessing directives start)
Section C.8.3 (#if and #elif)
Section C.8.3 (comments on preprocessor directives)
Section C.8.3 (preprocessor directives order of checking)
Section C.8.6 ('null' preprocessor directive)
Section D.1.2 (external identifiers on headers)
Section D.9.5.6 ( printf arguments)
volatile
----------------------------------------------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section A.7 (Compliance)
To: std-c@cbosgd
* Section A.7, page 3:
Strictly conforming programs are intended to be maximally
portable.
Given that "strictly conforming programs" can be written that won't
run on any existing implementations, delete the above sentence--
or change it to something like:
Strictly conforming programs are intended to be maximally
portable among different conforming hosted implementations.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section B.2.2 (alert character)
To: std-c@cbosgd
* Section B.2.2, page 9:
\a (alert) Produces an implementation-defined. . .alert
character. Any consequent alteration to the printing
position is implementation-defined.
First, change the second sentence to read "The printing position
is left as is."
Second, change the alert escape to \!, to allow for graceful degradation
of programs shipped to "old" (that is, current) systems--doing a
printf("Wake up\!\n");
would produce
Wake up
followed by an alert character on conforming hosted implementations,
and would produce
Wake up!
on current systems.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.1.3.2 (integer suffix)
To: std-c@cbosgd
* Section C.1.3.2, page 18:
integer-suffix:
integer-suffix-letter
integer-suffix-letter integer-suffix-letter
integer-suffix-letter: one of
u l U L
By this definition,
0uu
is a (very unsigned?) integer constant. If this is the standard's
intent, fine; otherwise, go back to the definition of
integer-suffix used in the November, 1984 draft.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.1.7 (comments)
To: std-c@cbosgd
* Section C.1.7, page 22:
The contents of a comment are examined only to find the
characters */ that terminate it. Thus comments do not nest.
and section E.3, page 135, listing "common warnings":
The characters /* are found in a comment.
Sorry. . .if you're only allowed to look for the */ that terminates
a comment, you can't look for a /*. Change the first quote to:
The contents of a comment are examined to find the characters
*/ that terminate it. Comments do not nest.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.3 (grouping of operations)
To: std-c@cbosgd
* Section C.3, page 26:
To force a particular grouping of operations, either the value
of an expression to be grouped may be explicitly assigned to
an object, or grouping parentheses may be preceded by a unary
plus or minus operator.
and section C.3.3.3, page 31:
. . .Except that it inhibits regrouping, the expression +E
is equivalent to (0+E).
. . .The expression -E is equivalent to (0-E).
The first quote indicates that with respect to inhibiting regrouping,
unary plus and unary minus are the same, so the last quotes should
be either:
. . .The expression +E is equivalent to (0+E).
. . .The expression -E is equivalent to (0-E).
or:
. . .Except that it inhibits regrouping, the expression +E
is equivalent to (0+E).
. . .Except that it inhibits regrouping, the expression -E
is equivalent to (0-E).
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.3.3.4 (sizeof)
To: std-c@cbosgd
* Section C.3.3.4, page 32:
Another use of the sizeof operator is to compute the number of
members in an array:
sizeof(array)/sizeof(array[0])
The parentheses can be dispensed with here--and I think it's a good
idea to dispense with them, to ensure that implementors get the idea
that parentheses are optional when sizeof is applied to a
unary-expression. Change the example to read:
sizeof array / sizeof array[0]
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.5.2 type-specifier
To: std-c@cbosgd
* Section C.5.2, page 42:
type-specifier:
...
const
volatile
Change to:
type-specifier:
...
constant
volatile
and change all other references to the keyword "const". I've noted
before that I like seeing things spelled out in full. A new note:
using "constant" rather than "const" is less likely to break existing
code, since it is a longer word, is therefore more likely to break
identifier-length limits in existing systems, and is therefore less
likely to appear as an identifier in existing programs.
[ This I heard, it is likely that more existing programs abound with
'constant' as an identifier name than 'const'. On the other hand, nobody
has found 'volatile' used as an identifier name. -- Mod -- ]
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.8 (preprocessing directives start)
To: std-c@cbosgd
* Section C.8, page 61:
[Preprocessing capabilities] are controlled by. . ."lines". . .
that "begin with" a # separator character; more precisely, by
a # token that is the first character in the source file (after
any number of space and horizontal-tab characters) or that
follows a new-line character (after any number of space and
horizontal-tab characters).
Elsewhere in the standard, vertical tabs and form feeds are allowed
as "white space"; for consistency and ease of implementation, they
should be allowed here also. Change both references to "any number
of space and horizontal-tab characters" to "any amount of white space."
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.8.3 (#if and #elif)
To: std-c@cbosgd
* Section C.8.3, page 64, describing constraints on "#if" and "#elif"
directives:
Constant expressions were discussed in SC.4. Additional
restrictions apply to a constant expression that controls
conditional inclusion: All arithmetic is done as if the
operands had type long int in the translation environment. . .
I'm unclear from this as to whether
#if 5.0
is a valid directive. I'm also unclear as to whether "arithmetic"
includes "comparison": does the constant expression in
#if 0xffffffffu > 0
evaluate to one or does it evaluate to zero?
Here's what I'd like to see (which may be different from the committee's vision):
Constant expressions used in preprocessor directives must be
integral constant expressions as discussed in SC.4, with
additional restrictions: All arithmetic (including comparison)
is done as if the operands had type long int in the translation
environment. . .
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.8.3 (comments on preprocessor directives)
To: std-c@cbosgd
* Section C.8.3, page 65:
However, comments may appear anywhere on any source line,
including on a preprocessor directive.
and section C.8.6, page 65:
If there is no token between the # and the next new-line
character, the directive has no effect.
The first quote implies that
#/* This is a comment */
is valid; the second implies that it is not (the comment gets turned
into a white-space token which appears between the # and new-line).
If the committee feels compelled to keep the null preprocessor
directive, either remove the first quote or change the second to:
If there is only white space (or nothing) between the # and
the next new-line character, the directive has no effect.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.8.3 (preprocessor directives order of checking)
To: std-c@cbosgd
* Section C.8.3, page 64:
Each directive's condition is checked in order. If it
evaluates to false(0), the program text that follows is skipped;
directives are verified for correctness, but processed only to
keep track of the level of nested conditionals.
Suppose I write
#ifdef vax
#define product(a, b) ((a) * (b))
#endif
/*...*/
#ifdef vax
#if product(3, 4) == 25
printf("Inflation has set in.");
#endif
#endif
I've tried to use the "product" macro only when I've defined it, but
since even skipped directives are "verified for correctness" the above
code will generate an error.
Change the quote to:
Each directive's condition is checked in order. If it
evaluates to false(0), the program text that follows is skipped;
directives are processed only to keep track of the level of
nested conditionals.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section C.8.6 ('null' preprocessor directive)
To: std-c@cbosgd
* Section C.8.6, page 65, describes a "null preprocessor directive."
Use of such directives adds no new functionality and impairs portability
to older systems. Remove the section and all references to the null
preprocessor directive.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section D.1.2 (external identifiers on headers)
To: std-c@cbosgd
* Section D.1.2, page 67:
All external identifiers declared in any of the headers are
reserved, whether or not the associated header is included.
All external identifiers that begin with an underscore are
also reserved. . .An implementation may define macros whose
names begin with two or more underscores, even if no headers
are explicitly included.
While "identifier reservation" has been reworded and put on a new page,
it is still one-sided. Add something like the following:
Only identifiers that are declared in any of the headers or
that begin with an underscore are reserved. Defined macro names
other than those defined in headers and those beginning with two
or more underscores must be documented for each implementation.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: Section D.9.5.6 ( printf arguments)
To: std-c@cbosgd
* Section D.9.5.6, page 96:
If any argument is or points to an aggregate (except for an
array of characters using %s conversion or any pointer using
%p conversion), the behavior is undefined.
Since "sizeof (char *)", "sizeof (int *)" and "sizeof (void *)" may
not all be the same, I imagine that the behavior of at least
one of the printfs in the code
{
int * ip;
char * cp;
printf("%p%f\n", ip, 1.0);
printf("%p%f\n", cp, 1.0);
}
is undefined. Change the quote to something like:
If any argument is or points to an aggregate (except for an
array of characters using %s conversion or a pointer to type
void using %p conversion), the behavior is undefined.
------------------------------
Date: Thu, 20 Jun 85 15:43:57 EDT
From: seismo!elsie!ado
Subject: volatile
To: std-c@cbosgd
* And a question: is an explanation of the semantics (if any) of
code such as
{
extern int i, j, k, l;
(volatile) (i = (j + k) + l);
i = (volatile) ((j + k) + l);
i = ((volatile) (j + k)) + l;
}
in order?
SOMEWHAT NEW NOTE***************************************************************
------------------------------
End of mod.std.c Digest - Mon, 24 Jun 85 18:24:09 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.