From: Eli Zaretskii <eliz@gnu.org>
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc/rft] [3/3] Remove stabs target macros: SOFUN_ADDRESS_MAYBE_MISSING
Date: Mon, 08 Oct 2007 23:17:00 -0000 [thread overview]
Message-ID: <uzlytmk4i.fsf@gnu.org> (raw)
In-Reply-To: <200710081119.l98BJalB008158@d12av02.megacenter.de.ibm.com> (uweigand@de.ibm.com)
> Date: Mon, 8 Oct 2007 13:19:36 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> Cc: gdb-patches@sourceware.org
>
> > . Please put the function prototypes where you describe them. For
> > example:
> >
> > > -@item SOFUN_ADDRESS_MAYBE_MISSING
> > > -@findex SOFUN_ADDRESS_MAYBE_MISSING
> > > +@item int gdbarch_sofun_address_maybe_missing
> > > +@findex gdbarch_sofun_address_maybe_missing
> >
> > The old SOFUN_ADDRESS_MAYBE_MISSING was a macro without arguments, but
> > the new gdbarch_sofun_address_maybe_missing is a function that accepts
> > arguments. The @item line should show the full prototype of the
> > function, including the type(s) of its argument(s).
>
> Well, the sofun_address_maybe_missing gdbarch entry is of type "v",
> i.e. it is a simple variable of type "int", not a function.
Okay, that means my example was chosen wrongly (but please do state
somewhere that this is a variable). However, IIRC you have other
changes where a macro is replaced with a function, but arguments of
that function are not shown, and that's what I'd like you to fix. A
reader of the manual should not need to consult sources to understand
how to define such a function.
> I guess the question is, what is the entity that the documentation
> should specify for gdbarch entries:
>
> - the gdbarch_... accessor function
> or
> - the argument passed to the set_gdbarch_... routine
Whatever replaced the old macro should be documented in its stead. I
thought you replaced macros with functions, but maybe I misunderstood.
> > . Some of the changes were too mechanical: replacing a macro with a
> > function sometimes needs more elaborate changes in the text to
> > avoid unclear or incorrect wording:
>
> This is because I was describing a boolean "int" value, not a
> function.
I think I saw such problems with functions as well. But if you state
clearly which ones are variables, I'll be glad to review the patch
again.
Thanks.
next prev parent reply other threads:[~2007-10-08 20:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-05 18:06 Ulrich Weigand
2007-10-06 7:16 ` Eli Zaretskii
2007-10-08 11:19 ` Ulrich Weigand
2007-10-08 23:17 ` Eli Zaretskii [this message]
2007-10-09 19:55 ` Ulrich Weigand
2007-10-09 23:29 ` Eli Zaretskii
2007-10-14 20:32 ` Ulrich Weigand
2007-10-14 22:16 ` Eli Zaretskii
2007-10-15 14:10 ` Ulrich Weigand
2007-10-15 17:53 ` 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=uzlytmk4i.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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