#include "filename" incorrectly (?) looks in ancestor directories

When a file is included by another (parent) file, and has #include "name.h", the first place to look for name.h is in the directory containing the parent file. pcpp does this correctly. However, if name.h is not found there, then pcpp next looks in the parent's parent's directory, and if that fails, moves up to the next level of parent. gcc does not do this. The Microsoft C compiler does this. clang also does this if it is installed as a Microsoft compatible compiler, with a warning that it is using a nonstandard Microsoft extension. Note that the ISO C and C++ standard documents only say that the search paths for the "name" and forms of #include are each implementation-defined. Let's look at an example.

Directory x:
    File x/main.c:
        #include "y/hdr.h"
   Directory x/y:
        File x/y/hdr.h:
           #include "z/hdr2.h"
        Directory x/y/z
            File x/y/z/hdr2.h:
                #include "hdr3.h"
                #include "hdr4.h"
        File x/y/hdr3.h:
            ...
    File x/hdr4.h:
        ...

Actual behavior

pcpp will find both x/y/hdr3.h and x/hdr4.h.

Expected behavior

The #include "hdr4.h" should fail (that is, unless it is found in some directory given by a "-I" option).

Suggestion

If you do want to support the current behavior, then it should require some command line switch, along with a warning that the non-standard Microsoft search was used.

ned14 / pcpp