[LLVMbugs] [Bug 15802] New: On windows %INCLUDE% ending in \ leads to clang hanging when trying to kick of new process

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15802
           Summary: On windows %INCLUDE% ending in \ leads to clang
                    hanging when trying to kick of new process
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: van_kessel at freenet.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10389
  --> http://llvm.org/bugs/attachment.cgi?id=10389&action=edit
possible patch

On Windows, invoking "clang test.c" makes clang hang during startup if
%INCLUDE% ends in a \ and presumably some similar conditions as well.

The problem has been described by user qble on
http://stackoverflow.com/questions/15992645/clang-compiler-hangs-on-windows

When clang gets invoked with actual work, it assembles a list of arguments and
kicks of a new process. Among those arguments is the include environment
variable on windows. In case this variable contains spaces or some other (e.g.
"C:\Program Files\SomeVendor\Include\") or some other special characters, clang
adds quotation marks around this string so that it stays a single argument to
the new process. If the argument ends in an uneven number (typically one) of
backslashes though, the quotation mark becomes escaped and thus instead of a
invocation like

clang "C:\Program Files\SomeVendor\Include\\" someOtherArg

which makes 

argv[1] = "C:\\Program Files\\SomeVendor\\Include\\"
argv[2] = "someOtherArg"

it becomes

clang "C:\Program Files\SomeVendor\Include\" someOtherArg

which is a unterminated 

argv[1] =  "C:\\Program Files\\SomeVendor\\Include\" someOtherArg ...


The problem can easily be fixed by escaping uneven trailing backslashes by just
adding another one. I have added a pach to llvm\lib\Support\Windows which fixes
the problem, I didn't feel like messing around with c-strings like the rest of
that code does. If you feel strongly about it, I could also write a patch in
keeping with the c-style code and without unnecessary copies (though I don't
think that code is remotely performance critical)

-- 
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/20130420/63741a8e/attachment.html>