This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/61922] New: Recursive #include overruns Win32 MAX_PATH due to lack of path canonization


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]