Poorly terminated header files.
Robert Thau
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