Path: utzoo!attcan!uunet!mcrware!jejones
From: jejones@mcrware.UUCP (James Jones)
Newsgroups: comp.os.os9
Subject: Re: osk 2.3, various woes, usenet for osk, and so forth...
Summary: relative paths in nested #includes, etc.
Message-ID: <3343@mcrware.UUCP>
Date: 11 Oct 90 16:32:10 GMT
References: <112@blars>
Reply-To: jejones@mcrware.UUCP (James Jones)
Organization: Microware Systems Corp., Des Moines, Iowa
Lines: 47

In article <112@blars> blarson@blars writes:
>"." is apperently no longer included in the default include file
>search rules in the C compiler.  Adding "-v=." to a make file fixed
>this.  (This only applies to compiling files out of subdirectories.)

K&R 1st edition says the following about #include semantics, in canonically
vague fashion:

"A compiler control line of the form

	#include "filename"

causes the replacement of that line by the entire contents of the file
filename.  The named file is searched for first in the directory of the
original source file, and then in a sequence of standard places."

The 2**6 dollar question is, is "the original source file" the file
whose name was initially handed to the compiler, or the file containing
the #include directive?  The preprocessor formerly thought it was the
former, and indeed X3J11 seems to think, if one reads the Rationale,
that the former was intended--but the commonly-used Unix C preprocessor
behaves as if the latter were intended.  There were sufficient complaints,
not to mention that the latter interpretation makes somewhat more sense
by making nested #includes with relative pathnames not depend on the
path of the file being compiled, that cpp's interpretation was changed
to the latter, as, I recall, mentioned in release notes.  (That's not
the only debatable behavior of cpp.  K&R 1st edition's "Text inside
a string or a character constant is not subject to replacement" in 12.1
versus cpp's, and Reiser's, behavior on

#define ctrl(a) ('a' - ' ')

char	ctrlx = ctrl(x);

is another example.)

>Microware should worry about fixing the bugs and making their compiler
>ANSI compatable before seriously considering changes like register use
>on argument passing.

To the best of my knowledge, Microware's 680xx C compiler parameter
passing, aside from the relatively recent changes to let one pass
structures and unions, has been unchanged for a long time.  The most
recent changes to improve code generation have involved taking advantage
of the "as if" rule by avoiding superfluous widening of operands.

	James Jones