From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-50569-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 11867 invoked by alias); 31 Aug 2007 08:50:56 -0000
Received: (qmail 11859 invoked by uid 22791); 31 Aug 2007 08:50:55 -0000
X-Spam-Check-By: sourceware.org
Received: from heller.inter.net.il (HELO heller.inter.net.il) (213.8.233.23)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 31 Aug 2007 08:50:52 +0000
Received: from HOME-C4E4A596F7 (IGLD-83-130-237-140.inter.net.il [83.130.237.140]) 	by heller.inter.net.il (MOS 3.7.3a-GA) 	with ESMTP id DMS33658 (AUTH halo1); 	Fri, 31 Aug 2007 11:50:45 +0300 (IDT)
Date: Fri, 31 Aug 2007 08:50:00 -0000
Message-Id: <uabs8140p.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Vladimir Prus <ghost@cs.msu.su>
CC: drow@false.org, gdb-patches@sources.redhat.com
In-reply-to: <200708311105.38612.ghost@cs.msu.su> (message from Vladimir Prus 	on Fri, 31 Aug 2007 11:05:37 +0400)
Subject: Re: [mi] -list-features
Reply-to: Eli Zaretskii <eliz@gnu.org>
References: <fb1l06$dl3$1@sea.gmane.org> <200708282147.18298.ghost@cs.msu.su> <ur6lmb4z3.fsf@gnu.org> <200708311105.38612.ghost@cs.msu.su>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2007-08/txt/msg00542.txt.bz2

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 31 Aug 2007 11:05:37 +0400
> Cc: drow@false.org,
>  gdb-patches@sources.redhat.com
> 
> How about this:
> 
>         -list-features
>                 Returns a list of particular features of the MI protocol that
>                 this version of gdb implements.  A feature can be a command,
>                 or a new field in an output of some command, or even an
>                 important bugfix.  While a frontend can sometimes detect presence
>                 of a feature at runtime, it is easier to perform detection at debugger
>                 startup. 
> 
> 		The command returns a list of strings, with each string naming an
> 		available feature. Each returned string is just a name, it does not
> 		have any internal structure. The list of possible feature names 
> 		is given below.

It is still ambiguous, because "a list of string" does not tell the
whole story.  Is it

    foo bar baz
or
    "foo" "bar" "baz"
or
    foo,bar,baz
or
    {foo,bar,baz}
or
    ...

You get the story.

I think an example will go a long way towards disambiguating this.

Thanks.