Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: PATCH: copy-edit File-I/O section of manual
Date: Fri, 09 Jun 2006 19:43:00 -0000	[thread overview]
Message-ID: <uac8mqfnk.fsf@gnu.org> (raw)
In-Reply-To: <4465ED4D.4020505@codesourcery.com> (message from Sandra 	Loosemore on Sat, 13 May 2006 10:29:33 -0400)

> Date: Sat, 13 May 2006 10:29:33 -0400
> From: Sandra Loosemore <sandra@codesourcery.com>
> 
> When I was implementing the File-I/O protocol recently, I noticed a lot of 
> spelling and grammatical mistakes in that section of the manual.  Here's a patch 
> to clean it up.
> 
> 2006-05-13  Sandra Loosemore  <sandra@codesourcery.com>
> 	* gdb.texinfo (File-I/O remote protocol extension): General
> 	copy-editing to fix spelling, grammar, formatting issues.
> 	Moved a few paragraphs around to more logical places.

Thanks.  I finally found time to review this.  I have some minor
comments and suggestions:

>   @node The Ctrl-C message
>   @subsection The Ctrl-C message
>   @cindex ctrl-c message, in file-i/o protocol
>   
> ! If the @var{Ctrl-C flag} is set in the @value{GDBN}

The @var markup is inappropriate here.  I think we should just remove
the markup, and maybe add an @pxref to the section where this flag is
described (in case the reader needs to consult the context).

> ! @table @asis
> ! @item Synopsis:
> ! @code{int open(const char *pathname, int flags);}@*
> ! @code{int open(const char *pathname, int flags, mode_t mode);}
>   
> ! @item Request:
> ! @code{Fopen,@var{pathptr}/@var{len},@var{flags},@var{mode}}

I agree that the original's playing with @exdent was egregious, and
that @table is better.  But why not have the code samples in
@smallexample?  That's what it's for.  Plus, you won't need the @*
thingies then.

> ! writing (@code{O_RDWR} or @code{O_WRONLY} is given) it will be
>   truncated to length 0.
                 ^^^^^^^^
"zero length" is better, I think.

> ! @var{mode} is the bitwise or of the following values:

Perhaps "@code{OR}" is better than just "or".

> ! In case @code{/bin/sh} could not be executed, 127 is returned.

"/bin/sh" should have the @file markup, not @code.

> + to the target.  Basically, the only signal transmitted back is @code{EINTR}

This text is confusingly inaccurate: signals aren't transmitted back,
they cause an errno value to be transmitted back.  Here, the SIGINT
signal causes EINTR to be put into the return value.  I suggest to
rephrase this.

> + @item show remote system-call-allowed
> + @kindex show remote system-call-allowed
> + Show the current setting of system calls for the remote File I/O
> + protocol.

I think this is better:

  Show whether the @code{system} calls are allowed in the File I/O
  protocol.


> ! @item st_uid
> ! No valid meaning for the target.  Transmitted unchanged.
>   
> ! @itemx st_gid
> ! No valid meaning for the target.  Transmitted unchanged.
>   
> ! @item st_rdev
> ! No valid meaning for the target.  Transmitted unchanged.

Isn't it better to group these together (with @itemx)?

> ! @item st_atime, st_mtime, st_ctime

These _definitely_ should use @itemx, instead of having them all on
the same line.

Do you have write access to the CVS repository?  If so, please commit
after you take care of these comments, but please make the ChangeLog
entries more detailed (every node in which a change is made should be
mentioned).

Thanks again for taking time to fix these blunders.


  parent reply	other threads:[~2006-06-09 19:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-13 14:32 Sandra Loosemore
2006-05-13 19:03 ` Eli Zaretskii
2006-05-14  3:29   ` Sandra Loosemore
2006-05-14  6:35     ` Eli Zaretskii
2006-05-14 15:01       ` Sandra Loosemore
2006-05-14 15:10         ` Daniel Jacobowitz
2006-05-14 19:44           ` Sandra Loosemore
2006-05-14 22:06             ` Eli Zaretskii
2006-05-15 15:09               ` Sandra Loosemore
2006-05-15 20:44                 ` Eli Zaretskii
2006-05-14 20:15           ` Eli Zaretskii
2006-05-14 20:21             ` Daniel Jacobowitz
2006-05-14 20:12         ` Eli Zaretskii
2006-06-09 19:43 ` Eli Zaretskii [this message]
2006-06-10 18:50   ` Sandra Loosemore
2006-06-10 21:34     ` Eli Zaretskii

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=uac8mqfnk.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=sandra@codesourcery.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