Re: Fixinc and mvme328.h

[Bruce Korb <korb at datadesign dot com>]

Manfred Hollstein wrote:
> 
> On Fri, 15 January 1999, 11:32:20, manfred@s-direktnet.de wrote:
> 
>  >
>  > If nobody objects, I'll check this in tonight. OK?
>  >
> 
> Nobody did, so I just checked the patch below into CVS
> (diffs for configure omitted here).

I thought I had thanked you.  If not, then my belated thanks. :)

>  > Manfred Hollstein wrote:
>  > > 
>  > > I've just been running my fixed version of fast-fixincludes on both
>  > > Motorola systems.  Both terminated with similar problems:
>  > > 
>  > > /usr/include/sys/mvme328.h includes (besides other stuff) this:
>  > > 
>  > > #include "sys/m328sio.h"
>  > > #include "sys/m328scsi.h"
>  > > 
>  > > fixinc then fails to find those files, because it's looking for them
>  > > in "sys/sys/m328sio.h", thus it's simply appending the directory part
>  > > to the directory where it found the original file.
>  > > 
>  > >   Fixed:  ./sys/mvme328.h
>  > >   Quoted includes in ./sys/mvme328.h
>  > >   ./fixinc.sh: ./sys/sys/m328sio.h: does not exist
>  > > 
>  > > Shouldn't it append the "sys/" behind the *first* original starting
>  > > directory instead?
>  > 
>  > Well, actually the semantics, as best I understand ANSI, are that
>  > when the quotes are '"', then the file is searched for first from
>  > the directory where the including file was found.  If that fails,
>  > then the search begins just as if it were quoted with '<' and '>'.
>  > Under that algorithm, it should be looking for it in ./sys/sys/.
>  > When not found, it will later be found when /usr/include is examined
>  > during the normal search sequence.
>  > 
>  > Also, I think the old fixincludes worked this way.  The difference is
>  > that with -DDEBUG, you see the message:
>  > 
>  > >   ./fixinc.sh: ./sys/sys/m328sio.h: does not exist
>  > Yes?  No?
> 
> No!
> 
> At least, this is not how "gcc -ansi" and "gcc -traditional" behave:

I think so.  Please read on.

> $ cat t.c
> #include <sys/mvme328.h>
> $ cat include/sys/mvme328.h
> #include "sys/m328sio.h"
> 
> int this_is_include_sys_mvme328_h = 1;
> $ cat include/sys/m328sio.h
> int this_is_include_sys_m328sio_h = 1;
> $ gcc -c -I`pwd`/include -ansi -H t.c
> /home/manfred/zoo/include/sys/mvme328.h
>  /home/manfred/zoo/include/sys/m328sio.h
> $ gcc -c -I`pwd`/include -traditional -H t.c
> /home/manfred/zoo/include/sys/mvme328.h
>  /home/manfred/zoo/include/sys/m328sio.h
> $ 
> 
> I believe, you need to change fixincl's behaviour, right?

I believe you need another test.
You cannot emulate the context of the derived header files
from the command line in this fashion.  By my understanding,
in the processing of your test, the compiler first tried
to open "`pwd`/include/sys/" '+' "sys/m328sio.h"  (the directory
of the <sys/mvme328.h> plus the file name it included with the
'"' construct).  That failed silently.  It then tried to open
"`pwd`/include/" '+' "sys/m328sio.h" (the path specified with
the -I option, plus the file name).  That succeeded.  Here is how
to test the problem:

1.  Create *two* directories  inc1/sys and inc2/sys.
2.  In *both* directories, create a file named m328sio.h.
    In inc1/sys/m328sio.h let the contents be:

	int foo = 1;

    In inc2/sys/m328sio.h let the contents be:

	#error bogus

3.  in inc1/sys create the file mvme328.h that has:

	#include "sys/m328sio.h"

4.  Compile your t.c as follows:

	gcc -Iinc2 -Iinc1 -H t.c

    with or without -traditional or -ansi.  It fails:

> gcc -Iinc2 -Iinc1 -H t.c
> inc1/sys/mvme328.h
>  inc2/sys/m328sio.h
> In file included from inc1/sys/mvme328.h:1,
>                  from t.c:1:
> inc2/sys/m328sio.h:1: #error bogus

So, I continue my claim that the program as it exists is correct.  :-}
I do hate esoterica.  Are there any language lawyers out there?


I think the correct thing is to fix the #include statement.
I do not know if the correct fix is

	#include "m328sio.h"
or
	#include <sys/m328sio.h>

The former is precisely correct.
Either should do it.
If the latter breaks, then you must have file name conflicts
that have incompatible contents.  Unlikely at best.

It seems to me that there is such a fix for one of the oddball
"fixinc.*" files, but I may be misremembering.