Re: cpp strange behavior for #line and #include

[Craig Burley <burley at gnu dot org>]

>"/net" is often special -- it's the default place for some automounters
>to intercept mount requests.
>
>  > Thus, when cpp attempts to open the above file, it hangs, just
>  > as it would if the file happened to be an NFS filesystem whose
>  > host was down, or some such thing.
>Yup, this sounds more and more like the automounter was sitting on
>/net intercepting mount requests.

Thanks to you and Richard for pointing this out to me.

Back to the main issue -- which is that #line directives in C source
files often, in practice, contain pathnames that are completely
irrelevant, and therefore potentially "dangerously" erroneous,
to the build environment for such files, yet that #include in gcc
tries to use them.

Is it reasonable to simply eliminate this "feature" of #line?  That
is, have #line no longer put the filename/pathname into the list
of ones to be searched?

Since the ANSI C standard (at least the 1988-12-07 draft copy I
have) doesn't mandate this behavior, nor does the gcc/cpp documentation,
I'd recommend that, because it's really a subtle misfeature.  (Both
documents appear to *allow* this misfeature, however!  That is,
ANSI C says the search order for #include is implementation-defined,
and the cpp docs just don't get clear enough to tell either way.)

If there's a concern over possible packages out there that depend
on this misfeature, we could add some kind of new -I option
(another syntactic kludge like `-I-', maybe `-I--' ;-) to
explicitly specify that the current misfeature is desired.

A short example of how this misfeature causes evil things to happen:

Jane Q. Hacker writes a package and distributes it to the public:

/home/jane/package/foo.h:
--------
#define SOMEVAL 2
--------

/home/jane/package/foo.y:
--------
...
#include "foo.h"
... { printf ("%d", SOMEVAL); } ...
--------

In the package she distributes foo.c, which is automatically derived
by running bison over foo.y, as usual.

Now, Tug D. Boat downloads the package and builds it.  He's unpacked
it in

  /home/tug/package/

but is unaware that his co-worker, Jane-Bob Biggles, happens to have
the following file in her directory:

/home/jane/package/foo.h:
--------
#define SOMEVAL 3
--------

The result is that gcc's cpp will silently pick up Jane-Bob Biggles',
not Jane Q. Hacker's, foo.h file, silently compile it, and silently
produce a broken executable.

Yes, I realize this would be an "amazing coincidence".

However, in my experience, most bugs that take the most experienced
talent available hours, days, weeks, even months to find, are the
result of an "amazing coincidence" combined with some poor design
decisions that gave the coincidence its buggy impact.

In my case, this misfeature took about an hour or so to track down.
(Interrupting the preprocessor once it hung wasn't very helpful,
as the stack was corrupt at that point for some reason; I had to
resort to arbitrary cut-save-retry-and-repaste for several iterations,
finally, to discover what combination of text caused the problem.)

        tq vm, (burley)