joe.cvl.umcp-cs@UDel-Relay (03/22/83)
I don't know if anyone's mentioned this before, but it seems to be pretty annoying (in the sense of unexpected behavior). The C shell says that '#' introduces a comment (remainder of line is ignored) whenever the shell's standard input is not a terminal, rather than when the shell is not interactive. As a consequence, command arguments containing '#' may screw up when passed to 'csh -c command args ...' I found this out the hard way when using the spell command in Gosling's emacs. The compile-it function apparently calls a C shell (at least when your environment SHELL variable says that's your shell), and my file-name would get truncated silently UNLESS I did an interactive compile-it. It really seems that comments should be recognized only in non-interactive shells which aren't started with '-c'. Does anyone have a reason not to do this?
crc (04/06/83)
I think # should ALLWAYS be recognised as a comment or NEVER. Having things secretly change on you is a good way of getting stabbed in the back.
tjr (04/29/83)
Beware of an inconsistency in the UNIX 4.0 (etc.) C-compiler and the basic reference manual for the C language: sizeof(object) is NOT "semantically an integer constant" [Kernighan and Ritchie, "The C Programming Language", p188]. sizeof(object) appears to be an unsigned integer. This is reasonable (especially on 16-bit machines), but can cause problems: In UNIX 5.0 message routines, msgrcv returns the number of bytes in the received message, or -1 to indicate an error. This does NOT work: if(msgrcv(...) >= sizeof(struct msg)) handle_message(); If msgrcv() detects an error (e.g. no message to read), its return-value of -1 is converted to unsigned int before the comparison, which will then always succeed! This works: if(msgrcv(...) >= (int)sizeof(struct msg)) handle_message(); Tom Roberts ihnet!tjr