osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (08/12/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Mon, 12 Aug 85 Volume 9 : Issue 2
Today's Topics:
more comments on the standard
----------------------------------------------------------------------
Date: Tue, 6 Aug 85 20:21 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: more comments on the standard
To: cbosgd!std-c@BERKELEY (NOT to INFO-C)
comments on the April 30, 1985 DRAFT standard.
section C.3.3.2
The & (address-of) operator needs to have some constraints put on it's
argument. As the standard currently reads "&2" is legal. So is "&++a".
And lots of other bad stuff.
(the syntax is a follows:
unary-op cast-expr -> & unary-exp ->...-> & primary-expr -> & constant -> & 2
" " -> & unary-op cast-expr ->...-> & ++ a
)
section C.8.1
#include <s-char-seq>
#include "s-char-seq"
I've already mentioned that not allowing '>' in the first form is bad
news. However, if you must keep it this way, note that the description
of what #include "s-char-seq" says that if it fails its read as
#include <s-char-seq>. A phrase should be added to the effect that
'>'s are OKay (and need not be escaped if you allow \> in the first
kind.)
Also in this section, we find that the last character in an include file
must be a new-line. Why? The complier can always stick in a new-line
if it wants one.
section D.5.4.6
int modf( double value, double *intptr) ; /* return fractional part of value */
/*and puts the int part in *intptr */
"modf" is a horrible name. (Among other things there is an
fmod. Or maybe this is fmod and I've confused the two.) Call it "fracf"
(or anything else) and if the intptr argument is absent or NULL don't
bother with the int part.
section D.6.2.1
Is there a good reason why you can't let longjmp have setjmp return 0?
All it means is making the code a little more confusing. Admitedly,
maybe a warning is in order, but to forbid it all together?
Mark
^.-.^ Purtill at MIT-MULTICS.ARPA **Insert favorite disclaimer here**
((")) 2-032 MIT Cambrige MA 02139
------------------------------
End of mod.std.c Digest - Mon, 12 Aug 85 08:47: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.