[LLVMbugs] [Bug 20440] New: Recursive #include overruns MAX_PATH due to lack of path canonization

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20440

            Bug ID: 20440
           Summary: Recursive #include overruns MAX_PATH due to lack of
                    path canonization
           Product: clang
           Version: 3.4
          Hardware: PC
                OS: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: ilya.konstantinov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 12821
  --> http://llvm.org/bugs/attachment.cgi?id=12821&action=edit
Simple 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. Microsoft Visual C++ handles it well.
(gcc fails similarly.)

Curiously, merely recursively including the same file does not reproduce it,
probably due to directory caching of some sort in HeaderSearch::LookupFile.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140724/2f10f36b/attachment.html>