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

[Joe Grace]

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.

[By the way, if you add -I. to the command line, cpp finds ./2.h --- fine.
 Unfortunately, if you have both a ./2.h *and* a bar/2.h, it finds
 bar/2.h instead of ./2.h (Argghhrrrr --- this is actually where I
 need the other behavior!).]

Is this behavior generally broken or am I missing something?

Thanks,

= Joe =
(followup-to:  comp.lang.c)
Joe Grace
ARPA: jgrace at bbn.com
UUCP: {harvard,husc6,decvax,etc.}!bbn!jgrace
#include <StandardDisclaimer.h>