<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:rnk@google.com" title="Reid Kleckner <rnk@google.com>"> <span class="fn">Reid Kleckner</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - Regression in batch file quote handling"
href="https://bugs.llvm.org/show_bug.cgi?id=39506">bug 39506</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>WONTFIX
</td>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - Regression in batch file quote handling"
href="https://bugs.llvm.org/show_bug.cgi?id=39506#c4">Comment # 4</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED WONTFIX - Regression in batch file quote handling"
href="https://bugs.llvm.org/show_bug.cgi?id=39506">bug 39506</a>
from <span class="vcard"><a class="email" href="mailto:rnk@google.com" title="Reid Kleckner <rnk@google.com>"> <span class="fn">Reid Kleckner</span></a>
</span></b>
<pre>So, apparently the CRT and CommandLineToArgvW have different behaviors in
obscure cases like these.
I was referred to these comments in Chromium's source code:
<a href="https://cs.chromium.org/chromium/src/chrome/install_static/install_util.cc?type=cs&q=%3E%5C+TokenizeCommandLineToArray+file:install_util%5C.cc&sq=package:chromium&g=0&l=742">https://cs.chromium.org/chromium/src/chrome/install_static/install_util.cc?type=cs&q=%3E%5C+TokenizeCommandLineToArray+file:install_util%5C.cc&sq=package:chromium&g=0&l=742</a>
// This is baroquely complex to do properly, see e.g.
// <a href="https://blogs.msdn.microsoft.com/oldnewthing/20100917-00/?p=12833">https://blogs.msdn.microsoft.com/oldnewthing/20100917-00/?p=12833</a>
//
<a href="http://www.windowsinspired.com/how-a-windows-programs-splits-its-command-line-into-individual-arguments/">http://www.windowsinspired.com/how-a-windows-programs-splits-its-command-line-into-individual-arguments/</a>
// and many others. We cannot use CommandLineToArgvW() in chrome_elf, because
// it's in shell32.dll. Previously, __wgetmainargs() in the CRT was
available,
// and it's still documented for VS 2015 at
// <a href="https://msdn.microsoft.com/en-us/library/ff770599.aspx">https://msdn.microsoft.com/en-us/library/ff770599.aspx</a> but unfortunately,
// isn't actually available.
//
// This parsing matches CommandLineToArgvW()s for arguments, rather than the
// CRTs. These are different only in the most obscure of cases and will not
// matter in any practical situation. See the windowsinspired.com post above
// for details.
//
// Indicates whether or not space and tab are interpreted as token
separators.
When we switched to CommandLineToArgvW back in r192069
(<a href="http://reviews.llvm.org/D1834">http://reviews.llvm.org/D1834</a> from 2013), we didn't intend to change behavior
from the tokenization that the CRT performs when it populates argv for a
regular 'main' prototype. I believe that the recent change in r341988 brought
us back to the CRT behavior. I'm going to close wontfix to acknowledge that
this was a behavior change, but we intend to stick with it.
If you want to reopen, use this program with various batch file invocations and
compare what it prints to how clang understands its command line:
#include <stdio.h>
int main(int argc, char **argv) {
for (int i = 0; i < argc; ++i)
puts(argv[i]);
}
I suspect that if you invoke it like you did clang:
// run.bat
foo.exe -c -x assembler-with-cpp -DFOO="""%~1""" bar.s -o bar.out.o
Usage:
C:\Work>run.bat 123
I believe (don't have a Windows machine to test at the moment) it will print:
foo.exe
-c
-x
assembler-with-cpp
-DFOO=123
bar.s
-o
bar.out.o
If you get a different tokenization, we can re-evaluate.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>