osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/17/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Tue, 16 Jul 85 Volume 8 : Issue 10
Today's Topics:
C.5.3.3 Function declarators & C.7.1 Function definitions
C.8.2 Macro replacement
C.8.3 Conditional inclusion
C.8.5 Pragma directive
C.8 Preprocessing Directives
----------------------------------------------------------------------
Date: Sat, 13 Jul 85 00:20:34 edt
From: hcr!lsuc!msb
Subject: C.5.3.3 Function declarators & C.7.1 Function definitions
To: hcr!cbosgd!std-c
I see the attraction of allowing the style
int max (int a, int b)
for both a function prototype and a function header, but nevertheless,
I wonder if we really need two ways to declare a function header.
I think that if the language was being redesigned from scratch then
it would be appropriate to add the above syntax in place of the
traditional
int max (a, b) int a,; int b;
but I don't see that there is any need to add it now (unless there are
already some important compilers out there which accept it -- are there?).
The syntax is also somewhat confusing since it conflicts with that of
ordinary declarations:
char a, b; int c;
but
int f (char a, char b, int c)
One could also complain about the allowing of ignored identifiers in a
function prototype when then are being disallowed in #endif. Inconsistent.
------------------------------
Date: Sat, 13 Jul 85 00:20:34 edt
From: hcr!lsuc!msb
Subject: C.8.2 Macro replacement
To: hcr!cbosgd!std-c
* 1. It is really intended that M(f(p,q)) is a macro call with one argument
but M(a[p,q]) is a macro call with two arguments, right? (This seems quite
reasonable -- I just wanted to point out that parens aren't the only things
that pair. Maybe there should be a note.)
* 2. "each instance of the token ## is deleted, and the tokens preceding
and following it are concatenated to a single token".
Add: "if possible". Note that this implies that, for instance, + ## +
becomes a ++ operator. But + ## - would have to become + - .
Also, perhaps it is worth noting explicitly what / ## * does! I take
it that it becomes a divide operator followed by an indirection operator,
since comments are removed before preprocessing.
------------------------------
Date: Sat, 13 Jul 85 00:20:34 edt
From: hcr!lsuc!msb
Subject: C.8.3 Conditional inclusion
To: hcr!cbosgd!std-c
* 1. Somebody proposed earlier that #elif be changed to #elseif. I propose
that it be changed to the more C-like
# else if
Even if trailing identifiers become legal again after #else (which I, too,
would like), this syntax is still unambiguous since "if" is not a legal
identifier.
* 2. Why is constant-expression arithmetic restricted to long ints without
casts?
* 3. The note "... a token must not follow a #else or #endif directive
before the terminating new-line. However, comments may appear ..."
forgets that both comments and white space are tokens.
------------------------------
Date: Sat, 13 Jul 85 00:20:34 edt
From: hcr!lsuc!msb
Subject: C.8.5 Pragma directive
To: hcr!cbosgd!std-c
The syntax
# pragma x-char-sequence new-line
x-char-sequence: sequence of x-char's
x-char: any character in the source character set except new-line
does not take account of the fact that an x-char-sequence as defined could
begin with spaces or tabs, which would actually be swallowed by the preceding
spaces/tabs. Or is this taken care of by the same rule in C.1 that says
that x+++++y is not legal because it becomes x++ ++ +y?
------------------------------
Date: Sat, 13 Jul 85 00:20:34 edt
From: hcr!lsuc!msb
Subject: C.8 Preprocessing Directives
To: hcr!cbosgd!std-c
* 1. It should be noted that the syntax divides white space characters
into not two but three types: (1) new-lines, (2) spaces and tabs, and
(3) vertical tabs and form-feeds. The latter characters are not mentioned
in this section of the document, which appears to mean that they are treated
like non-white-space characters for the purpose of parsing preprocessor
directives. I don't see any advantage to this, and I propose that the
group 3 characters should be lumped in with group 1 or 2 -- to my mind,
preferably group 1, since this is how I think of them.
If this is not done, something explicit should at least be noted about
the treatment of group 3 characters.
* 2. The note "'Lines' have not other syntactic significance, as all white
space is equivalent except in preprocessing directives" should be amended
to mention string literals and character constants.
------------------------------
End of mod.std.c Digest - Tue, 16 Jul 85 22:45:51 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.