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: unassignedclangb...@nondot.org
Reporter: ilya.konstanti...@gmail.com
CC: llvmbugs@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.
_______________________________________________
LLVMbugs mailing list
LLVMbugs@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
