cpp strange behavior for #line and #include

[Craig Burley]

I just ran into a very weird bug that took awhile to track down.
The symptom was that building binutils-2.8.1.0.15 (recommended
for egcs) hung when compiling ld/ldgram.c.

The apparent cause of the problem is that this file, ldgram.c,
contains a directive of the form:

#line 20 "/net/ocean/blahblahblah..."

Subsequently, this line appears:

#include "bfd.h"

cpp treats the latter as a possible reference to the following file:

  /net/ocean/blahblahblah.../bfd.h

(With the final filename of blahblahblah... stripped, of course.)

On my system, /net is, for some reason I don't fully understand,
not readable -- it hangs when you do `ls /net'.

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.

I can't see anything in the cpp docs that explain that #line
changes the name used for looking up files in #include, at least
not clearly.

In particular, #line (and `# ') seem to be designed to, and widely
used for, change only the *output* name and the __FILE__ macro
name -- not anything else like #include search orders.

If this behavior of cpp is wrong, it should be fixed (even
egcs-1.0.1 has this bug).

If it is correct, all tools that produce C code (bison, flex, and
so on) should be changed to no longer emit #line directives, as
these are no longer useful, or perhaps no products should ship
any files output by these tools, thus forcing end users to
regenerate them using source-file locations that, presumably, will
work on the source systems.  These seem like extreme measures,
so I would hope that simply eliminating the cpp behavior is best,
but maybe that is not possible.

Although the workaround is simple for me, the problem is quite
hard to diagnose and will have various weird behaviors on
various systems, depending on what a pathname that means one
thing on one system happens to mean on another.  But I don't know
enough about the history of these various tools and formats to
guess at what would be the best solution.

        tq vm, (burley)

- --QAA20289.885332780/mescaline.gnu.org--
------- End of forwarded message -------