From: Simon Marchi <simon.marchi@ericsson.com>
To: Tom Tromey <tromey@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH] PR mi/15806: Fix quoting of async events
Date: Fri, 16 May 2014 19:57:00 -0000 [thread overview]
Message-ID: <53766D85.3070402@ericsson.com> (raw)
In-Reply-To: <87ha4p60qg.fsf@fleche.redhat.com>
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
<!-- hel\lo \n-->
to its output.
Before:
Packet received: l<threads> <!-- hel\\lo \\n-->\n<thread id="p7bbe.7bbe" core="1"/>\n</threads>\n
After:
Packet received: l<threads> <!-- hel\lo \n-->\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
next prev parent reply other threads:[~2014-05-16 19:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-27 3:08 Simon Marchi
2014-04-28 18:36 ` Marc Khouzam
2014-05-12 17:56 ` Simon Marchi
2014-05-16 15:42 ` Tom Tromey
2014-05-16 17:58 ` Simon Marchi
2014-05-16 18:24 ` Tom Tromey
2014-05-16 19:57 ` Simon Marchi [this message]
2014-05-16 20:17 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53766D85.3070402@ericsson.com \
--to=simon.marchi@ericsson.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox