mod.std.c Digest V7#3 (repeat)

[Orlando Sotomayor-Diaz]

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 at MIT-MULTICS.ARPA>
Subject: Section B.2.4.1 Translation limits 
To: cbosgd!std-c at 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 at MIT-MULTICS.ARPA>
Subject: Section C.1.2 Identifiers
To: cbosgd!std-c at 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 at MIT-MULTICS.ARPA>
Subject: Section C.3.15 Conditional operator
To: cbosgd!std-c at 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 at MIT-MULTICS.ARPA>
Subject: Section C.4 Constant Expressions
To: cbosgd!std-c at 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 at MIT-MULTICS.ARPA>
Subject: Section C.5.3.3 Function declarators
To: cbosgd!std-c at 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 at MIT-MULTICS.ARPA>
Subject: Section C.8.1 Source file inclusion
To: cbosgd!std-c at 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 at MIT-MULTICS.ARPA>
Subject: Section C.8.3 Conditional inclusion
To: cbosgd!std-c at 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 at MIT-MULTICS.ARPA>
Subject: Section D.9.7.11 The ungetc function
To: cbosgd!std-c at 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 at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.