From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14515 invoked by alias); 12 Feb 2004 06:26:59 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14508 invoked from network); 12 Feb 2004 06:26:58 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 12 Feb 2004 06:26:58 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.24) id 1ArAIb-0005ED-8I; Thu, 12 Feb 2004 01:26:09 -0500 Date: Thu, 12 Feb 2004 06:26:00 -0000 Message-Id: From: Eli Zaretskii To: Roland McGrath CC: cagney@gnu.org, gdb@sources.redhat.com In-reply-to: <200402120211.i1C2Bw7f011025@magilla.sf.frob.com> (message from Roland McGrath on Wed, 11 Feb 2004 18:11:58 -0800) Subject: Re: remote protocol support for TARGET_OBJECT_AUXV Reply-to: Eli Zaretskii References: <200402120211.i1C2Bw7f011025@magilla.sf.frob.com> X-SW-Source: 2004-02/txt/msg00119.txt.bz2 > Date: Wed, 11 Feb 2004 18:11:58 -0800 > From: Roland McGrath > > Here is proposed wording for a protocol based on your comments. > I have the implementation ready to go as well. If the implementation is approved, here are my comments about the documentation patch: > +@item @code{E}@var{NN} > +The request is bad, the offset is invalid, > +or there was an error encountered reading the data. I suggest using @var{nn} (lower-case) instead of @var{NN}, since that should look better in the printed manual. Also, please explain in the text what does @var{nn} stand for; I assume it's a number that tells what kind of error happened, but I think the manual shouldn't leave that to reader's guesses. > +@table @samp I don't think @samp is appropriate here: it puts every item in quotes, which is a bit ugly. Your @item's already have the necessary markup (@code etc.), so I'd suggest to use "@table @asis" instead. > +@item @var{NN} > +@var{NN} (hex encoded) is the number of bytes written. For consistency, I'd suggest to use @var{XX} here, as you did in a previous table. > +@item @code{E}@var{NN} > +The request is bad, the offset is invalid, > +or there was an error encountered writing the data. See the comment above about @var{NN}. > +@item @code{} > +An empty reply indicates the @var{object} or @var{annex} string was not > +recognized by the stub, or that the object does not support writing. The empty item is confusing and will look awkward in print, I think. How about this instead: @item @code{""} (empty) ? Thanks.