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 3
Today's Topics:
Section B.2.4.1 Translation limits
Section C.1.2 Identifiers
Section C.3.15 Conditional operator
Section C.4 Constant Expressions
Section C.5.3.3 Function declarators
Section C.8.1 Source file inclusion
Section C.8.3 Conditional inclusion
Section D.9.7.11 The ungetc function
----------------------------------------------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section B.2.4.1 Translation limits
To: cbosgd!std-c@BERKELEY
Ref. Doc.: X3J11/85-045
Comments on preliminary draft proposed ANSI C, dated April 30, 1985
In general, I think the standard is pretty well done. There
are a few picky details that bothered me, tho. I've tried to avoid
mentioning things that have been hashed to death already, but one or two
of my comments may repeat things others have said.
Section B.2.4.1 Translation limits
> The implementation must be able to compile at least one
>program that or exceeds all of the following translation limits:
Is that really what you mean? Shouldn't it be something like:
The implementation must be able to compile all legal programs
which do not exceed the following translation limits:
>* maximum number of alphabetic cases in an external identifier (1)
after the above line, may I suggest adding:
* maximum number of alphabetic cases in an internal identifier or macro name(2)
>* maximum length of input program logical source lines (509)
Why 509? Seems like a rather strange number.
Also, I would like to see a "note" here to the effect that if
an implementation can provide larger numbers for any of these, that's
great, and in particular encouraging implementors to provide two case/
thirty-one character external identifiers if possible.
------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section C.1.2 Identifiers
To: cbosgd!std-c@BERKELEY
Section C.1.2 Identifiers
Constraints In a "note" in section D.1.3, it is mentioned that
> As stated previously, external identifiers beginning with underscore
> are reserved.
I couldn't find the previous reference. It should be mentioned in this
section (C.1.2), or a forward reference given. Also, I understood that
all identifiers starting with two underscores ("__", as in __LINE__)
were reserved as well, but I can't find that, either.
Re: my previous message (above)
I've found where it talks about reserving external identifiers starting
with _ and all identifiers starting with __. (section D.1.2) I still
think there should be a forward reference in section C.1.2.
------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section C.3.15 Conditional operator
To: cbosgd!std-c@BERKELEY
Section C.3.15 Conditional operator
>Syntax
> conditional-expression:
> logical-OR-expression
> logical-OR-expression ? logical-OR-expression : conditional-expression
This allows a?b:c?d:e but not a?b?c:d:e, which seems strange, especially
as I prefer the second. (The first could be read as (a?b:c)?d:e, but
the second is unambiguous). I suggest changing the last line to
logical-OR-expression ? conditional-expression : conditional-expression
------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section C.4 Constant Expressions
To: cbosgd!std-c@BERKELEY
Section C.4 Constant Expressions
Constraints
Aw, gee, the language of this section makes "a"[0] not an "integral
constant expression" (as used in case statements), because it disallows
array-subscripting ([]) in them. How about allowing array-subscripting
iff the array in question is "array of constant <type>" and the
subscript is constant? (I'll bet there are real uses for this, not just
my stupid CTRL(X) macro.) You should also allow (equivalently) *pointer
iff pointer is a constant pointer to constant <type> (since that's just
pointer[0]). One could also make a case for allowing . and -> iff the
appropriate things are constant.
------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section C.5.3.3 Function declarators
To: cbosgd!std-c@BERKELEY
Section C.5.3.3 Function declarators
It would be nice if in a non-definition declaration for a function,
f(...) was allowed, meaning no information given (just like f() now.)
(This is the usage in C++.) Also, in function definitions, it would be
neat if you could say f(void) { /*...*/ }, meaning no arguments
(currently f() { /*...*/ }). (This would mean that you could always add
on a function definition to a function declaration lacking one.)
------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section C.8.1 Source file inclusion
To: cbosgd!std-c@BERKELEY
Section C.8.1 Source file inclusion
Constraints
In a # include <file> new-line, '>' may not appear in "file." This is
bad news because many file systems use '>' in their file names. (e.g.,
MULTICS, whatever RUTGERS.ARPA runs, VMS allows it in place of ], etc.)
Furthermore, its not necessary, since the final '>' can be identified by
the fact that there is only (possibly) white-space and a new-line
following it. I.e.,
#include <sys>stuff.h> /* even if there's a comment */
is strange looking, but unambiguous. The constraint should be omitted,
or, at worse, allow '\>' for '>'.
------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section C.8.3 Conditional inclusion
To: cbosgd!std-c@BERKELEY
Section C.8.3 Conditional inclusion
"elif" is an extremely ugly name. Furthermore, one can't replace it (like
on can other ugly names like "const") with the preprocessor since it's a
preprocessor thing. Please replace it with "elseif", which is clearer,
and looks more like "endif".
------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section D.9.7.11 The ungetc function
To: cbosgd!std-c@BERKELEY
Section D.9.7.11 The ungetc function
How about a limit macro, UNGETC_PUSHBACK_LIMIT, indicating how many
characters one is guaranteed to be able to push back. (It would have to
be at least 1., of course.) Also, some versions of ungetc (or similar)
only allow one to pushback the last character(s) read. The standard
should clearly state that any character can be pushed back.
------------------------------
End of mod.std.c Digest - Mon, 24 Jun 85 17:48:37 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.