Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>, Will Newton <will.newton@linaro.org>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Support _Complex in hard-VFP abi
Date: Wed, 20 Aug 2014 08:21:00 -0000	[thread overview]
Message-ID: <53F45A61.1050304@redhat.com> (raw)
In-Reply-To: <53F41920.8040800@codesourcery.com>

On 08/20/2014 04:42 AM, Yao Qi wrote:
> On 08/20/2014 06:44 AM, Pedro Alves wrote:
>> This is borderline pedantry, but this looks ugly enough to me that
>> I'll speak up in case this ends up being the norm.  :-)  FWIW, I agree
>> with Will here -- I think we should make an exception to the rule
>> in the cases where the comment is actually a paste of output,
>> multiline code or similar cases.  It's kind of like a @smallexample
>> region in texinfo, that begs to be rendered on its own block/lines,
>> separate from the text around it.
> 
> I am fine with this exception here, but we'd better document it.
> 
> The rule is documented here
> https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards
> 
> Block comments must appear in the following form, with no /*- or */-only lines, and no leading *:
> 
> /* Wait for control to return from inferior to debugger.  If inferior
>    gets a signal, we may decide to start it up again instead of
>    returning.  That is why there is a loop in this function.  When
>    this function actually returns it means the inferior should be left
>    stopped and GDB should read more commands.  */
> 
> I propose to add the following words after this paragraph above,
> 
> "Exceptionally, */ can be put at a separate line if the comment is ended
> with an example, an output or a code snippet:
> 
> /* Arguments of complex T where T is one of the types float or
>    double get treated as if they are implemented as:
> 
> struct complexT
> {
>   T real;
>   T imag;
> };
> 
> */"
> 

That's excellent, IMO.

> The patch below updates the comments I've seen in current code base.
> 

Looks great to me.

Thanks,
Pedro Alves


  reply	other threads:[~2014-08-20  8:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-11 12:56 Yao Qi
2014-08-11 13:12 ` Will Newton
2014-08-19 13:16   ` Yao Qi
2014-08-19 22:44     ` Pedro Alves
2014-08-20  3:46       ` Yao Qi
2014-08-20  8:21         ` Pedro Alves [this message]
2014-08-20 10:26           ` Yao Qi
2014-08-19  0:55 ` Yao Qi
2014-08-19  7:00   ` Joel Brobecker

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=53F45A61.1050304@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=will.newton@linaro.org \
    --cc=yao@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