This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/5] Add annex in a async remote notification.
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 16 Feb 2013 11:26:56 +0200
- Subject: Re: [PATCH 1/5] Add annex in a async remote notification.
- References: <1358838232-13319-1-git-send-email-yao@codesourcery.com> <1358838232-13319-2-git-send-email-yao@codesourcery.com> <83fw1tod6e.fsf@gnu.org> <511EFE76.4030506@codesourcery.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Sat, 16 Feb 2013 11:35:18 +0800
> From: Yao Qi <yao@codesourcery.com>
> CC: <gdb-patches@sourceware.org>
>
> On 01/22/2013 04:05 PM, Eli Zaretskii wrote:
> > Is it a good idea to have the optional part in the middle? If there
> > are MI clients out there that support the previous form, they might
> > now confuse ANNEX to be an EVENT.
>
> It can't be confused. The "optional" here means some notifications have
> annexes and some don't. Given an notification, the annexes of it are
> determined, and annex is separated with event by ":".
Sorry, I don't follow your reasoning.
My concern was about the following use case:
. an old MI client that only supports the old "name:event" form
. a notification is sent in the new form "name:annex:event"
. the MI client only parses the first 2 parts, and confuses "annex"
for "event"
How can we be sure this can never happen? We have no idea what MI
clients are out there, they are out of control of GDB development.