https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61922
Bug ID: 61922 Summary: Recursive #include overruns Win32 MAX_PATH due to lack of path canonization Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ilya.konstantinov at gmail dot com Created attachment 33190 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33190&action=edit Minimal testcase When #include "..." is relative to the including file's directory, clang performs simple path concatenation. FOR EXAMPLE, if foo/foo.h includes "../bar/bar.h", clang will ask the OS to open "foo/../bar/bar.h" -- i.e. it will not canonize the path to "bar/bar.h". Normally, the OS handles this under the hood. However, Win32 CreateFile only accepts up to 260 (a.k.a MAX_PATH) characters. With sufficiently long and contrived chains of relative #includes, which actually occurred in a real-life project of mine, it can overrun MAX_PATH and result in erroneous "File not found". TESTCASE: I'm attaching a reproducing testcase. On Microsoft Visual C++, it compiles correctly. clang has the same issue: http://llvm.org/bugs/show_bug.cgi?id=20440