Why don't nested #include's start at the source directory?

[c9h at psuecl.bitnet]

In article <49549 at bbn.COM>, jgrace at bbn.com (Joe Grace) writes:
> I have found a surprising, annoying and disappointing "feature" of
> both /lib/cpp (SunOS3.5) and GNU cpp:
>
> Given the files:
>
>   ./foo.c:
>   #include "1.h"
>
>   ./bar/1.h:
>   #include "2.h"
>
>   ./2.h:
>   2 /*  Just anything; cpp never finds this file!  */
>
>> /lib/cpp -Ibar foo.c  # produces:
> # 1 "foo.c"
>
> # 1 "bar/1.h" 1
>
> bar/1.h: 2: Can't find include file 2.h
> [Uhhh, no!  You can't find file ./bar/2.h but ./2.h certainly exists.
>  Why don't you use ./2.h?  And if both bar/2.h and ./2.h exist, I would
>  still want you to use ./2.h.]
> # 2 "foo.c" 2
>
>
> Now, 1.h exists in . so what's the problem?  This behavior seems both
> buggy and undesirable to me.  On the other hand, it seems unusual that
> this is a normal "bug" since one has to go to trouble (i.e., has to
> try) to get this behavior.

Whether or not this is a bug is a matter of opinion.  When you use quotes
around the filename in an #include statement, this generally means to search
in the *same* directory.  Now, here arises the question:  The same directory
as the file with the #include, or the same directory as the main program?

Personally, I prefer the former.

--
- Charles Martin Hannum II       "Klein bottle for sale ... inquire within."
    (That's Charles to you!)     "To life immortal!"
  c9h at psuecl.{bitnet,psu.edu}    "No noozzzz izzz netzzzsnoozzzzz..."
  c9h at eclx.psu.edu               "Mem'ry, all alone in the moonlight ..."
  c9h at hcx.psu.edu
  cmh at psuecl2.bitnet