bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/27594] build processes broken by changed space handling


From: martin at martin dot st
Subject: [Bug binutils/27594] build processes broken by changed space handling
Date: Mon, 10 May 2021 14:58:38 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=27594

--- Comment #9 from Martin Storsjö <martin at martin dot st> ---
(In reply to Eli Zaretskii from comment #8)
> Quoting with backslashes also doesn't work in cmd.exe.  The suggestion to
> pre-quote the preprocessor is also unreliable, because when `windres` is run
> from cmd.exe or from the native MinGW Make, the program's startup code
> unquotes the argument, so the result will depend on how many "unquoting"
> levels the command line is subject to.

I would beg to differ here; when any shell, be it either bash or cmd.exe,
interprets a command line, it does split and unescape the command line
depending on that shell's rules.

It's true that the actual splitting and unescaping happens at different levels
(in the caller, in the case of unix shells, and in the callee in the case of a
win32 executable), but the basic principle is still the same; if I want to call
a tool and have it receive a specific argument, I have to quote that argument
according to the current shell's rules (and those rules differ with respect to
certain details).

So if I want to call windres so that it receives the argument "path to/gcc.exe"
-E -DRC_INVOKED, I can call windres with "\"path to/gcc.exe\" -E -DRC_INVOKED"
in cmd.exe and in bash - that particular quoting happens to work in both. In
bash I could also call it with single quotes and not needing to escape the
double quotes, as '"path to/gcc.exe" -E -DRC_INVOKED'.


Thomas - the patch that was applied today, in
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=749c700282097cf679ff019a9674d7c762f48619,
doesn't that adjust an entirely different thing? The quot() function isn't
called for --preprocessor arguments, it's only called for --preprocessor-arg
and -D and similar. It still just wraps the whole --preprocessor argument in
double quotes, here:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/windres.c;h=2b626a29fb68ada1cc012a267a60d72c1335bea9;hb=23182ac0d832477d316547ec2a758d22b43d0837#l889


I'm not arguing that what we have right now is pretty - it's not.

But the core issue - that the --preprocessor argument used to accept multiple
arguments (and where spaces would have to be pre-quoted) - do you want to
willingly break that, which multiple existing projects rely on? I agree that
the new interpretation of the option would be more straightforward to deal with
- but it is a breaking change that affects multiple projects. I'd rather try to
more clearly document the existing original behaviour and how to deal with it.



Eli - separately, the new quoting behaviour (that was reverted now,
needlessly?) is, in principle a good thing, but it's still missing to quote a
few tricky cases - namely backslashes and double quotes. And fixing that would
be breaking roughly a similar number of projects.

If I want to preprocess with the option e.g. -DSTRING="quotedstring", I want
windres to call popen with -DSTRING=\"quotedstring\", so I need to call windres
with -DSTRING=\\\"quotedstring\\\". So it would in theory be great if quot()
would handle proper escaping of backslashes and double quotes, but if we'd do
that change, we'd be breaking those existing users that have codified that case
of double escaping for such strings.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]