rgenter@BBN-LABS-B.ARPA (07/15/86)
I can think of one reason why the Reiser CPP treats free standing # as
a comment when not at the beginning of the line: this is was many assemblers
use as comments. However, /lib/cpp as shipped with vanilla 4.2 BSD just passes
it on through, causing /lib/ccom to barf with the classic:
illegal character 043 (octal)
cannot recover from earlier errors, I'm stupid! (er...goodbye!)
What is worse is when you have a header file that ends with an unterminated
comment, as in:
loser.h:
#define LAST_LOSER 99 /* the last loser (oops)... /*
main.c:
#include "loser.h"
#include "victim.h"
/* and now the code... */
Gee, where did victim.h go?
P.S.
Why does zarathustra.think.com think that it's New Year's Day, 1987?
Or has the ARPAnet finally gone translight?
--------
Rick Genter BBN Laboratories Inc.
(617) 497-3848 10 Moulton St. 6/512
rgenter@labs-b.bbn.COM (Internet new) Cambridge, MA 02238
rgenter@bbn-labs-b.ARPA (Internet old) linus!rgenter%BBN-LABS-B.ARPA (UUCP)chris@umcp-cs.UUCP (07/17/86)
In article <5722@think.COM> rst@think.COM (Robert Thau) writes: >What does X3J11 say about these cases, if anything? The last time I >looked at a draft standard, __LINE__ and __FILE__ were in it; what are >their values on the split line, if such things are allowed? `The last character in a source file included by a #include preprocessing directive shall be a new-line character that is not part of a token.' I recall, but cannot find, a statement to the effect that an unterminated line in an included file is essentially a syntax error. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
rst@think.COM (Robert Thau) (01/01/87)
After reading reams on token concatenation (and the portability of
lack thereof of various means of doing it), the semantics of #define,
#ifdef, defined() and friends, etc., ad libitum ad nauseam, I hesitate
to add yet another phenom to the fray, but here goes:
Recently, through no fault of my own (honest, guv'nor!) I wound up
including a header file with no terminating newline. The setup looked
like this:
(main-line)
#include <loser.h>
#include <victim.h>
... stuff which depends on victim.h being included ...
(loser.h)
struct foo { type bar; other-type zot; } glorp;
#define something else<EOF>
victim.h:
...
struct bar *somefunction();
<EOF>
The symptom was (if you haven't already guessed) that victim.h was not
actually included in the main-line, resulting in "illegal combination
of pointer and integer" error messages from both lint and cc (this on
4.2bsd) when I tried to use somefunction(). Adding the terminating
newline to loser.h solves the problem. (Thanks to J. P. Massar for help
in tracking this down).
This peculiar behavior arises because the Reiser cpp actually includes
the content of loser.h verbatim, leaving the "#include <victim.h>"
stranded on the middle of the last line of loser.h. Now, it is
definitely non-standard for cpp (and /lib/ccom) not to complain about
the # in the middle of the line. (The Reiser cpp treats the '#' in
the middle of a line as a comment character, and deletes text to the
next newline, which is certainly wrong). My questions are directed
more toward the handling of the missing newline itself:
What do other preprocessors do in this kind of situation?
What does X3J11 say about these cases, if anything? The last time I
looked at a draft standard, __LINE__ and __FILE__ were in it; what are
their values on the split line, if such things are allowed?
What *should* X3J11 say about these cases, if anything?
rst