Well, I don't think *any* of these cases come up in the wild, or gcc would have 
figured it out by now.  But once I had to look at this stuff anyway, I was too 
offended by it to leave things as they were.

GNU Make's rule is pretty straightforward, actually: backslashes escape the 
next character, but if a fully de-escaped filename doesn't find a match, retry 
with the original string.  GCC's rule is the one that's crazy, where 
de-escaping depends on what character follows the backslash.
--paulr

From: [email protected] [mailto:[email protected]] 
On Behalf Of Sean Silva
Sent: Friday, May 08, 2015 4:59 PM
To: Nico Weber
Cc: [email protected]; 
[email protected]
Subject: Re: [PATCH] Fix dependency file escaping

From a brief look at depfile_parser.in.cc<http://depfile_parser.in.cc>, it 
looks like Ninja does not correctly handle GCC's current behavior, and Paul's 
patch will actually make it "work". Clearly includes with `#` characters in 
them don't happen in practice.

Ninja's depfile_parser.cc tries to express the escaping rules as "backslash 
escapes certain characters", which is not the reality. Make's craziness is such 
that you cannot tell in isolation whether the backslashes in a substring 
`foo\\` need to be escaped or not without looking at the characters following 
that substring.

-- Sean Silva

On Fri, May 8, 2015 at 4:36 PM, Nico Weber 
<[email protected]<mailto:[email protected]>> wrote:
On Fri, May 8, 2015 at 4:01 PM, Paul Robinson 
<[email protected]<mailto:[email protected]>> 
wrote:
In http://reviews.llvm.org/D9208#169446, @thakis wrote:

> Does gcc intend to fix this soon? Isn't being compatible with gcc important
>  than the other things?


If gcc emitted an incorrect relocation, would you argue that it's important to 
be compatible with gcc?  Even if you could not point to any linker that handled 
that buggy relocation in a reasonable way?

'course not, but that's not the case here. If a program (say, ninja) tries to 
be compatible with gnu make's depfile parsing, it would previously convert "\ " 
to a space from what I understand. Now it's going to get "\\\ " and think that 
that's "\ ". So this is breaking backwards compat of clang with itself.

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to