https://sourceware.org/bugzilla/show_bug.cgi?id=27594
--- Comment #18 from Eli Zaretskii <eliz at gnu dot org> --- (In reply to Thomas Wolff from comment #17) > This is getting picky. I wouldn't say there's double quoting involved. > The string given to the -preprocessor arguments seems to be simply fed into > a call of popen(), and that should be fine. It may contain quotes as needed. The user isn't supposed to know that the program calls `popen`, nor should that knowledge change how users pass arguments to programs that need quoting. Moreover, `windres` calls `popen` only in its default mode; you could change that with the --use-temp-file option, in which case the preprocessor will be invoked via `pexecute`, and that has a different set of implementation-defined perculiarities wrt quoted parts of the command. > Quoting the whole argument again in the shell is not really double-quoting > in this sense. Only if you pass an argument that needs to remain quoted inside the program, as in -DSTRING=\"foo\". Here, you want the preprocessor to #define STRING to have the value "foo", with the quotes. The case which triggered this, where the quotes were used for file names or complete command lines, is not such a case: there the quotes were used to protect whitespace. > So "\"path to gcc\" arguments..." is neither a trick nor anything special to > remember, it's normal syntax in such use cases. I disagree, see above. > Whether the wrong commit was reverted or not I cannot judge right now, I was > only asking to restore the 2.35 behaviour which is consistent with general > POSIX string handling and which supports everything anyone needs. Breaking > such support after years is what's generally called a regression and it's > generally and rightfully frowned upon. I disagree here as well. If someone used the tool incorrectly, in direct contradiction to its docs, then backward compatibility doesn't apply, IMO. But again, it isn't my call. -- You are receiving this mail because: You are on the CC list for the bug.
