Re: Preprocessing oddity breaks binutils

Re: Preprocessing oddity breaks binutils

[Andreas Schwab]

Zack Weinberg <zack@rabi.columbia.edu> writes:

|> On Wed, 02 Jun 1999 12:04:06 -0400, Dave Brolley wrote:
|> >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?
|> 
|> FYI, cpplib uses the test.h in the subdirectory.  I agree with Mark that
|> this is the right thing - #line should not affect the search path.

But #line changes the file name.

The standard says that the place where to search is implementation
defined.  The cpp manual says: "It searches for a file named FILE first in
the current directory, [...].  The current directory is the directory of
the current input file."

About the #line directive the standard says:

       [#4] A preprocessing directive of the form

         # line digit-sequence "s-char-sequence-opt" new-line

       sets the presumed line  number  similarly  and  changes  the
       presumed  name  of the source file to be the contents of the
       character string literal.

Thus the current behaviour of cpp is more in the spirit of the standard,
and IMHO cpplib is wrong.

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Preprocessing oddity breaks binutils

[Mark Mitchell]

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

Re: Preprocessing oddity breaks binutils

[Dave Brolley]

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

Re: Preprocessing oddity breaks binutils

[Mark Mitchell]

>>>>> "Ian" == Ian Lance Taylor <ian@airs.com> writes:

    Ian> There is something odd going on with your build, because the
    Ian> CVS tree does not include any generated files.  It does
    Ian> include ldlex.l (not a generated file) but it does not
    Ian> include ldgram.h (a generated file).

Interesting.  I will investigate.  (Of course, this still leaves the
issue open for the preprocessor folks.)

Thanks!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Preprocessing oddity breaks binutils

[Andreas Schwab]

mark@codesourcery.com writes:

|> >>>>> "Andreas" == Andreas Schwab <schwab@issan.cs.uni-dortmund.de> writes:
|> 
|>     Andreas> Thus the current behaviour of cpp is more in the spirit
|>     Andreas> of the standard, and IMHO cpplib is wrong.
|> 
|> I disagree, but clearly the standard does not really specify behavior
|> here.

Yes, it's implementation defined, and gcc documents the current behaviour.

|> My original example indicates how hard it is to forsee what might
|> happen, given the current behavior.  In particular, in a package that
|> has srcdir/objdir builds, if you have built once in the srcdir (or if
|> the package distributes generated files in the srcdir), and you then
|> build in an objdir, all yacc-generated files get the wrong header.

If you have built in srcdir, then you must run make distclean before you
can build in a separate dir.  Then you have no duplicate headers which is
a Bad Thing to start with.

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org

Re: Preprocessing oddity breaks binutils

[mark]

>>>>> "Andreas" == Andreas Schwab <schwab@issan.cs.uni-dortmund.de> writes:

    Andreas> Thus the current behaviour of cpp is more in the spirit
    Andreas> of the standard, and IMHO cpplib is wrong.

I disagree, but clearly the standard does not really specify behavior
here.

My original example indicates how hard it is to forsee what might
happen, given the current behavior.  In particular, in a package that
has srcdir/objdir builds, if you have built once in the srcdir (or if
the package distributes generated files in the srcdir), and you then
build in an objdir, all yacc-generated files get the wrong header.
What you have yacc to to work around this problem?  Generate #line's
that refer to the objdir, rather than the srcdir?  But, that's not
where the source actually *is*, so then debugging wouldn't work.  I
suppose you could insert a #line for the objdir right before
#include'ing the header, but why should you have to?

There's really no way to resolve this debate, so I don't intend to
argue the point any further.  I'm happy to leave it in Dave and
Zack's capable hands!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Preprocessing oddity breaks binutils

[Zack Weinberg]

On Wed, 02 Jun 1999 12:04:06 -0400, Dave Brolley wrote:
>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?

FYI, cpplib uses the test.h in the subdirectory.  I agree with Mark that
this is the right thing - #line should not affect the search path.

zw

>
>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
>
>
>

Re: Preprocessing oddity breaks binutils

[mark]

>>>>> "Andreas" == Andreas Schwab <schwab@issan.cs.uni-dortmund.de> writes:

    Andreas> mark@codesourcery.com writes:

    Andreas> |> >>>>> "Andreas" == Andreas Schwab
    Andreas> <schwab@issan.cs.uni-dortmund.de> writes: |> |> Andreas>
    Andreas> Thus the current behaviour of cpp is more in the spirit
    Andreas> |> Andreas> of the standard, and IMHO cpplib is wrong.
    Andreas> |> |> I disagree, but clearly the standard does not
    Andreas> really specify behavior |> here.

    Andreas> Yes, it's implementation defined, and gcc documents the
    Andreas> current behaviour.

That's the best possible argument against my point of view.  If we
really documented this oddity, then it should probably stay.  And
cpplib should be changed.  Just for my own satisfaction, would you
mind pointing me at the place in the manual where we documented this?

    Andreas> If you have built in srcdir, then you must run make
    Andreas> distclean before you can build in a separate dir.  Then
    Andreas> you have no duplicate headers which is a Bad Thing to
    Andreas> start with.

Agreed.  But this is a really confusing failure mode!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Preprocessing oddity breaks binutils

[Ian Lance Taylor]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Tue, 01 Jun 1999 19:01:42 -0700

   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.)

There is something odd going on with your build, because the CVS tree
does not include any generated files.  It does include ldlex.l (not a
generated file) but it does not include ldgram.h (a generated file).

Ian

Re: Preprocessing oddity breaks binutils

[Andreas Schwab]

mark@codesourcery.com writes:

|> >>>>> "Andreas" == Andreas Schwab <schwab@issan.cs.uni-dortmund.de> writes:
|> 
|>     Andreas> mark@codesourcery.com writes:
|> 
|>     Andreas> |> >>>>> "Andreas" == Andreas Schwab
|>     Andreas> <schwab@issan.cs.uni-dortmund.de> writes: |> |> Andreas>
|>     Andreas> Thus the current behaviour of cpp is more in the spirit
|>     Andreas> |> Andreas> of the standard, and IMHO cpplib is wrong.
|>     Andreas> |> |> I disagree, but clearly the standard does not
|>     Andreas> really specify behavior |> here.
|> 
|>     Andreas> Yes, it's implementation defined, and gcc documents the
|>     Andreas> current behaviour.
|> 
|> That's the best possible argument against my point of view.  If we
|> really documented this oddity, then it should probably stay.  And
|> cpplib should be changed.  Just for my own satisfaction, would you
|> mind pointing me at the place in the manual where we documented this?

See my first mail, I have already quoted the relevant parts.

This behaviour is not odd at all.  The *source* is the bison input, not
the intermediate C file.  The behaviour of the preprocessor should not
depend on where you put the intermediate file.  All you look at is the
bison source, where you see the #include directive, and it would be quite
odd if the included file came from an unrelated directory, just because
there is an intermediate file somewhere.  All messages will also point to
the real source, just as if the intermediate file wasn't there.

Andreas.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org