osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/24/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Tue, 23 Jul 85 Volume 8 : Issue 15
Today's Topics:
Comments on Section B (4/30/85 draft)
Comments on Section C (4/30/85 draft)
Comments on Section D (4/30/85 draft)
Comments on the preprocessor (4/30/85 draft)
----------------------------------------------------------------------
Date: Tue, 16 Jul 85 20:38:34 PDT
From: Michael Gersten <packard!UCLA-LOCUS.ARPA!cc1>
Subject: Comments on Section B (4/30/85 draft)
To: cbosgd!std-c
B.1.2.3 All output directed to interactive devices must occur before new
interactivly generated input is accepted
Does this mean typeahead is illegal?
B.2.1 Trigraphs. Are these replaced EVERYWHERE? In character constants,
fine, but what about string constants? Besides, if the characters are
required in the source character set, why are trygraphs needed?
\a: Get rid of it. Not only is it implementation dependant, it is DEVICE
dependant. That means that any implementation must be capable of
supporting any arbitrary number of arbitrary alert mechanisms. What
happens on terminals that do not support chr$(7)=bell? Please don't say
toss them; I like my bell-less micro.
B.2.4.1 As long as there is this big change for tokanizing the
preprocessor, (I'll get back to that), is there a minimum length for
lines AFTER preprocessing (509 characters is before preprocessing from
the way it is worded; if every token is considered one character, thats
nice long lines.)
------------------------------
Date: Tue, 16 Jul 85 20:38:34 PDT
From: Michael Gersten <packard!UCLA-LOCUS.ARPA!cc1>
Subject: Comments on Section C (4/30/85 draft)
To: cbosgd!std-c
C.1.2.2 For an identifier of a function or object declared with file
scope, if the first declaration is the source file contains the keyword
s t a t i c, the identifier has internal linkage
This changes the global variable default to external.
C.1.4 Since string constants are now non-modifiable,
typedef char *STRING;
will not work. The only other alternative is
typedef char STRING[];
but this is less desireable for function arguments as it prohibits
walking through the array by advancing the pointer (at least on my c
compiler, and as far as I can tell, the draft)
C.1.5 Why no &~ assignment operator? (If the string lvalue something= expr
is lvalue = lvalue something expr, then &~= is well defined)
C.3.8 if p points to the last member of an array object, the pointer
expression p+1 is greater than p
I like this, but this needs clarification: It is illegal for the
compiler to put any data at the top of memory, and library routines such
as calloc cannot return pointers to the top of memory.
C.5.2 Ready for this?
int a;
f()
{
a;
}
Is the first line of function f an expression or a declaration?
declaration: declaration specifiers
declraration specifier: type specifier
If there are no type specifiers in a declaration, the type is taken to
be int.
C.5.3 Please clarify this section. It is unreadable. A few dozen examples
would help (1/2 :-))
------------------------------
Date: Tue, 16 Jul 85 20:38:34 PDT
From: Michael Gersten <packard!UCLA-LOCUS.ARPA!cc1>
Subject: Comments on Section D (4/30/85 draft)
To: cbosgd!std-c
D.7.1.1 Why require that ALL signals, even those not specified here, be
reset to default every time? All unixes have some signals that are not
reset; in some cases, it may make better sense to allow resetting to
SIG_HOLD instead of SIG_DFL.
D.9.4.4 How do you expect anyone to reasonably implement tmpnam? Let me
tell you what will not work--initially setting a character in the string
to 'A' and then 'B', 'C', etc. If you put the pid (unix systems) in, an
exec() will run into the same files; if you don't use the pid, the
system() call has the same problems. This is in relation to the minimun
of 25 names before repetition part; after an exec or system they will
repeat immediately.
D.9.5.2 fflush() should be defined for input files and mean flushing
input buffers (discarding typeahead)
D.9.5.6 (setvbuf()) '(the buffer will be flushed ... when input is
requested)'
But 'output may not be directly followed by input without an intervening
fseek() or rewind()', which flushes the buffers anyways. Does this mean
that if a file is _IOLBF that input and output operations may be freely
intermixed, or are two sections contradicting themselves?
D.9.6.2 (fscanf()) If conversion terminates on a conflicting input
character, the offending character is left unread in the input stream.
Unread, or ungetc()? The difference is that if it was ungetc'd, it may
not be possible for the user routine to ungetc() something else.
D.9.7.3 fputc should be required NOT to put EOF; this allows use of
while (fputc(fgetc(fp),stdout) != EOF);
loops.
D.10.3 Clarify that free() must not die if passed NULL since
{c,m,re}alloc can return such pointers.
Finally, I cannot belive that the library functions do not include an
ftruncate() call. Just because one operating system out there can't support
it very well (although a equivalent routine was posted to the net recently)
doesn't mean that all other o/s's which can support it should be punnished.
Besides, maybe if it goes into the C standard it will go into the unix
standard (wish, wish). If unix can't do it in 10 lines, unix should be
re-written. (Actually, 4.2 which does have it was a re-write. Hmm...)
------------------------------
Date: Tue, 16 Jul 85 20:38:34 PDT
From: Michael Gersten <packard!UCLA-LOCUS.ARPA!cc1>
Subject: Comments on the preprocessor (4/30/85 draft)
To: cbosgd!std-c
The preprocessor. Let me tell you about the preprocessor.
#define a a
#define test(a) a+a
test(b);
results in
#define test(a) a+a
test(b);
after preprocessing. Here's why
#define a a
is entered into the preprocessor
The line
#define test(a) a+a
is tokenized into
# define test ( a ) a + a
which is preprocessed and results in
# define test ( a ) a + a
However, despite the fact that this looks like a preprocessor directive, it
is not reprocessed as such.
What happens if
#define cat(a,b) a b
cat(__LI#,#NE__)
occurs? Is the result
__LINE__
or
__LI NE__
or
__LI # # NE__
The prohibitation of character and string constants in the replacement from
being rescanned is unnecessary; it is always possible to change the names of
the arguments so that no conflicts will occur. If you insist on leaving it as
is, please put in an equivalent to the #identifier=="identifier" for character
constants. (maybe @identifier == 'identifier)
Comments may appear on any sorce line, including a preprocessor directive
But what if they are unterminated? That is, what if the newline token that
ends the preprocessor is found inside the comment?
How about adding the keywords
#olddefs
and
#newdefs
Where lines under control of #newdefs behave as specified in the draft, while
lines under #olddefs will allow any arbitrary token sequence after an #ifdef,
#else, #elif, or #endif line, and refuse to acknolege a comment that crosses
two source lines as actually taking up two sorce lines. #olddefs would also
allow preprocessor lines to modify themselves and would not allow # or ##
modifiers.
------------------------------
End of mod.std.c Digest - Tue, 23 Jul 85 22:20:24 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.