Re: [PATCH] PR mi/15806: Fix quoting of async events

Simon Marchi
2014-05-16T19:57:18Z

On Fri 16 May 2014 02:24:07 PM EDT, Tom Tromey wrote:
> Tom> Did you check the other callers of printchar, even indirect ones?
> Tom> I did a spot check and didn't see any issues, but it would be reassuring
> Tom> if you could look.
>
> Simon> The only direct callers of printchar are fputstr_filtered,
> Simon> fputstr_unfiltered, fputstrn_filtered and fputstrn_unfiltered. To the
> Simon> best of my knowledge, the change should not impact the callers of
> Simon> those.
>
> Yeah, by "indirect ones" I meant callers of these as well.
> I looked through them. fputstr_unfiltered is safe. fputstrn_filtered
> is not used. But for fputstrn_unfiltered, I see in remote.c:
>
> static char *
> escape_buffer (const char *buf, int n)
> [...]
> fputstrn_unfiltered (buf, n, 0, stb);
>
> So it seems like this change could impact remote.
> To know for sure, you'd have to dig a bit deeper.
>
> One option might be to make QUOTER==-1 special, then update the call in
> mi_console_raw_packet.

Indeed, there will be a difference with backslashes in the "set debug remote 1" output. Here is a small test I did. I modified the qxfer threads handler to add



to its output.

Before:
Packet received: l<threads> \n<thread id="p7bbe.7bbe" core="1"/>\n</threads>\n
After:
Packet received: l<threads> \n<thread id="p7c79.7c79" core="1"/>\n</threads>\n

So yeah, here, we don't have a quoter, but we want to escape backslashes anyway.

As you suggested, quoter == -1 could have a special meaning to modify the behavior of printchar. However, I think we are mixing two things that are not related. Why should the fact that I want to escape the " character influence whether I want to escape \ ? And vice-versa. They seem quite independent to me. And if there are independent, it could mean we need two separate parameters, one saying if we want to escape a quoting character and another saying if we want to escape the backslashes. WDYT?

Simon