Re: Preprocessing oddity breaks binutils

[Dave Brolley <brolley@cygnus.com>]

I agree that this is probably a long standing quirk bug in the
preprocessor which is arguably a bug. Does anyone know of any source which
relies on the current behaviour?

Dave

Mark Mitchell wrote:

> It's impossible to build the current binutils in CVS because of what I
> think is a bug in the C preprocessor.  Consider the following
> directory layout:
>
>   linux1.codesourcery.com% ls -lR
>   total 2
>   drwxrwx--x   2 mitchell mitchell     1024 Jun  1 18:54 baz/
>   -rw-rw----   1 mitchell mitchell        7 Jun  1 18:49 test.h
>
>   baz:
>   total 1
>   -rw-rw----   1 mitchell mitchell       38 Jun  1 18:50 test.c
>   -rw-rw----   1 mitchell mitchell        0 Jun  1 18:49 test.h
>
> Suppose that baz/test.h is empty, but that the top-level baz.h
> contains a #error.  Suppose that test.c is:
>
>   #line 1 "../test.c"
>   #include "test.h"
>
> Now, suppose that in baz you run:
>
>   cpp test.c
>
> What happens is:
>
>   linux1.codesourcery.com% cpp test.c
>   In file included from ../test.c:1:
>   ../test.h:1: #error
>
> The standards are pretty obscure about what exactly a #line does, or
> for that matter, how the include path is searched, but I think this is
> very confusing behavior.  I would never guess, as a user, that what
> #lines are inserted in a source file would affect where we would
> search for the file.
>
> In the binutils case, what's happening is that a generated lexer (from
> lex) is being placed in the objdir, along with a a generated include
> file full of tokens.  However, there's *already* a file of tokens in
> srcdir.  When compiling the lexer, we get the old file of tokens,
> because the lexer contains #line directives referring back to the old
> lexer.
>
> Perhaps, in the interests of portability, some kind of modification to
> binutils or automake is a good idea as well.  (This is happenning with
> ldlex.l, ldgram.h, and friends in the `ld' subdirectory of binutils.)
>
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com