<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 27.04.2013 6:49, Jordan Rose wrote:<br>
</div>
<blockquote
cite="mid:A0966300-4493-43A1-81C9-62D5635FB695@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On Apr 26, 2013, at 19:46 , Anton Yartsev <<a
moz-do-not-send="true" href="mailto:anton.yartsev@gmail.com">anton.yartsev@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 27.04.2013 5:07, Jordan Rose
wrote:<br>
</div>
<blockquote
cite="mid:C10FA7B4-EB5F-4433-B93C-29C4E5B4F527@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div><br>
</div>
<div>
<div>On Apr 26, 2013, at 11:26 , Anton Yartsev <<a
moz-do-not-send="true"
href="mailto:anton.yartsev@gmail.com">anton.yartsev@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">On 22.04.2013 23:51, Jordan Rose
wrote:<br>
<blockquote type="cite"> Better MinGW support is
certainly welcome! A few comments, though...<br>
<br>
<br>
================<br>
Comment at: tools/scan-build/scan-build:1563<br>
@@ -1562,3 +1562,3 @@<br>
$ClangCXX = $Clang;<br>
-$ClangCXX =~ s/\-\d+\.\d+$//;<br>
-$ClangCXX .= "++";<br>
+if($^O =~/msys/) {<br>
+ $ClangCXX =~ s/.exe$/++.exe/;<br>
----------------<br>
Not being a native Perl hacker, I found this a bit
confusing. `$OSNAME` would have been a bit
friendlier.<br>
<br>
Also, this check //only// handles MinGW, correct? <a
moz-do-not-send="true"
href="http://perldoc.perl.org/perlvar.html#General-Variables">http://perldoc.perl.org/perlvar.html#General-Variables</a>
says that native Windows returns "MSWin32" here.<br>
<br>
================<br>
Comment at: tools/scan-build/c++-analyzer.win:3<br>
@@ +2,2 @@<br>
+<br>
+system ("ccc-analyzer @ARGV");<br>
----------------<br>
The reason we have c++-analyzer at all is so that we
can set run the underlying compilation with a C++
compiler. Simply forwarding c++-analyzer.win to
ccc-analyzer won't actually accomplish that --
you'll have to add a flag or enviroment variable
check to ccc-analyzer, which c++-analyzer.win can
set before invoking ccc-analyzer.<br>
<br>
Also, are you sure this won't destroy arguments with
spaces in them? (You can test with something like
`"-DSTR=macro with spaces"`.)<br>
<br>
<br>
<a moz-do-not-send="true"
href="http://llvm-reviews.chandlerc.com/D703">http://llvm-reviews.chandlerc.com/D703</a><br>
</blockquote>
Thanx for the review, all of your fears were
confirmed.<br>
Attached is a new patch.<br>
<br>
Temporary excluded phabricator from recipients.<br>
</blockquote>
</div>
<br>
<div>This doesn't actually fix either problem nicely. ;-)
The advantage of a symlink over a wrapper script is that
the indirection cost is <i>tiny...</i>at least on
platforms where that trick works. That said, it does
seem silly to have both a c++-analyzer symlink and a
c++-analyzer.win wrapper script. How about moving the
bulk of ccc-analyzer into a separate .pm file, which you
can then load from ccc-analyzer and c++-analyzer? That
solves the quoting problem, too.</div>
</blockquote>
Great idea! I'll try to implement it this way.<br>
<br>
<blockquote
cite="mid:C10FA7B4-EB5F-4433-B93C-29C4E5B4F527@apple.com"
type="cite">
<div><br>
</div>
<div>(What's wrong with this quoting? Well, what if there
are double quotes in the path? Better to sidestep the
issue altogether.)</div>
</blockquote>
Arguments, when passed to or from @ARGV, are seemed to be
splitted by quotes, if any, with qoutes removal, or by
spaces otherwise:<br>
<br>
------- script1.pl:<br>
foreach my $arg (@ARGV) {<br>
print "Argument to script1.pl: $arg\n";<br>
}<br>
print "\n";<br>
system ("perl script2.pl @ARGV");<br>
<br>
------- script2.pl:<br>
foreach my $arg (@ARGV) {<br>
print "Argument to script2.pl: $arg\n";<br>
}<br>
<br>
------- command and output with single quotes:<br>
perl script1.pl -PARAM1 "a b" -PARAM2 c<br>
<br>
Argument to script1.pl: -PARAM1<br>
Argument to script1.pl: a b<br>
Argument to script1.pl: -PARAM2<br>
Argument to script1.pl: c<br>
<br>
Argument to script2.pl: -PARAM1<br>
Argument to script2.pl: a<br>
Argument to script2.pl: b<br>
Argument to script2.pl: -PARAM2<br>
Argument to script2.pl: c<br>
<br>
<br>
------- command and output with double quotes:<br>
perl script1.pl -PARAM1 ""a b""<br>
<br>
Argument to script1.pl: -PARAM1<br>
Argument to script1.pl: a<br>
Argument to script1.pl: b<br>
<br>
Argument to script2.pl: -PARAM1<br>
Argument to script2.pl: a<br>
Argument to script2.pl: b<br>
<br>
<br>
------- command and output with mixed double quotes:<br>
perl script1.pl -PARAM1 '"a b"'<br>
<br>
Argument to script1.pl: -PARAM1<br>
Argument to script1.pl: "a b"<br>
<br>
Argument to script2.pl: -PARAM1<br>
Argument to script2.pl: a b<br>
</div>
</blockquote>
<br>
</div>
At least in a shell you can do this:
<div><br>
</div>
<div><span></span>% perl script1.pl "a \" b"</div>
<div><br>
</div>
<div>which leads to this:</div>
<div><br>
</div>
<div>
<div>Argument to script1.pl: a " b</div>
<div><br>
</div>
<div>sh: -c: line 0: unexpected EOF while looking for matching
`"'</div>
<div>sh: -c: line 1: syntax error: unexpected end of file</div>
</div>
<div><br>
</div>
<div>;-)</div>
<div>Jordan</div>
</blockquote>
Hmm, yes, my solution with adding extra quotes around arguments is
vulnerable to this hack :)<br>
<br>
<pre class="moz-signature" cols="72">--
Anton</pre>
</body>
</html>