This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/61922] New: Recursive #include overruns Win32 MAX_PATH due to lack of path canonization
- From: "ilya.konstantinov at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 26 Jul 2014 17:16:47 +0000
- Subject: [Bug c/61922] New: Recursive #include overruns Win32 MAX_PATH due to lack of path canonization
- Auto-submitted: auto-generated
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