From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <yao@codesourcery.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Don't check PST is NULL in read_symtab
Date: Fri, 11 Jan 2013 18:44:00 -0000 [thread overview]
Message-ID: <20130111184422.GO6143@adacore.com> (raw)
In-Reply-To: <50F05388.2090408@redhat.com>
> FWIW, I agree with both of you. I agree with assertion's
> roles. But I also agree with Yao that for functions that implement
> a class-like interface and take a "this" pointer, there's no need
> to sprinkle the codebase with "gdb_assert (self != NULL)" checks.
> BUT (!), when reading one of those functions, it's a bit more obvious
> and self-describing that the function takes a "this"-style pointer
> when the parameter is actually called "self", and / or at least is
> the first parameter in the function's signature. Like:
I agree with everything said above. Just to be extra clear, in
case I appeared to be insisting - I was just thinking about
the assert, not requesting it.
> static void
> dbx_psymtab_to_symtab_1 (struct objfile *objfile, struct partial_symtab *pst)
> {
>
> static void
> dbx_psymtab_to_symtab_1 (struct partial_symtab *pst, struct objfile *objfile)
> {
>
> static void
> dbx_psymtab_to_symtab_1 (struct partial_symtab *self, struct objfile *objfile)
> {
I like "self" quite a bit, except that it's a little bit less
descriptive that "pst". But for a "method", I think that's
acceptable.
> (It'd be even better for grepability/readability if the implementations
> and hook name agreed, like:
>
> - result->read_symtab = dbx_psymtab_to_symtab;
> + result->read_symtab = dbx_read_symtab;
>
> or
>
> - result->read_symtab = dbx_psymtab_to_symtab;
> + result->psymtab_to_symtab = dbx_psymtab_to_symtab;
Agree as well. I don't mind making these two changes after Yao's
commit goes it (unless Yao wants to take care of it, I don't mean
to cut in).
--
Joel
next prev parent reply other threads:[~2013-01-11 18:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 1:57 Yao Qi
2013-01-11 4:52 ` Joel Brobecker
2013-01-11 14:34 ` Tom Tromey
2013-01-11 14:56 ` Yao Qi
2013-01-11 15:06 ` Tom Tromey
2013-01-14 12:42 ` [committed]: " Yao Qi
2013-01-14 12:44 ` Yao Qi
2013-01-11 14:46 ` Yao Qi
2013-01-11 15:06 ` Joel Brobecker
2013-01-11 18:02 ` Pedro Alves
2013-01-11 18:44 ` Joel Brobecker [this message]
2013-01-14 12:42 ` Yao Qi
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=20130111184422.GO6143@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--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