From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA 2/2] Remove some clanups from solib-svr4.c
Date: Fri, 30 Mar 2018 19:12:00 -0000 [thread overview]
Message-ID: <79a2885c006051d0975ef5422d469ceb@polymtl.ca> (raw)
In-Reply-To: <87bmf5e66w.fsf@tromey.com>
On 2018-03-30 15:04, Tom Tromey wrote:
>>> - newobj = XCNEW (struct so_list);
>>> - old_chain = make_cleanup (xfree, newobj);
>>> - lm_info_svr4 *li = lm_info_read (ldsomap);
>>> - newobj->lm_info = li;
>>> - make_cleanup (xfree, newobj->lm_info);
>>> + gdb::unique_xmalloc_ptr<lm_info_svr4> li (lm_info_read (ldsomap));
>
> Simon> This is not an error because lm_info_svr4 is trivially
> destructible,
> Simon> but since we allocate it with "new", we might as well use a
> Simon> unique_ptr, it's more future-proof.
>
> Good catch, thanks.
>
> Simon> How about making lm_info_read return an
> std::unique_ptr<lm_info_svr4>?
>
> Simon> The patch LGTM with or without those changes.
>
> How's this?
LGTM, I just noted two nits:
> @@ -168,28 +168,24 @@ svr4_same (struct so_list *gdb, struct so_list
> *inferior)
> return (svr4_same_1 (gdb->so_original_name,
> inferior->so_original_name));
> }
>
> -static lm_info_svr4 *
> +static std::unique_ptr<lm_info_svr4>
> lm_info_read (CORE_ADDR lm_addr)
> {
> struct link_map_offsets *lmo = svr4_fetch_link_map_offsets ();
> - gdb_byte *lm;
> - lm_info_svr4 *lm_info;
> - struct cleanup *back_to;
> + std::unique_ptr<lm_info_svr4> lm_info;
>
> - lm = (gdb_byte *) xmalloc (lmo->link_map_size);
> - back_to = make_cleanup (xfree, lm);
> + gdb::byte_vector lm (lmo->link_map_size);
>
> - if (target_read_memory (lm_addr, lm, lmo->link_map_size) != 0)
> + if (target_read_memory (lm_addr, lm.data (), lmo->link_map_size) !=
> 0)
> {
> warning (_("Error reading shared library list entry at %s"),
> - paddress (target_gdbarch (), lm_addr)),
> - lm_info = NULL;
> + paddress (target_gdbarch (), lm_addr));
> }
Curly braces can be removed here.
> @@ -973,13 +965,8 @@ svr4_keep_data_in_core (CORE_ADDR vaddr, unsigned
> long size)
> if (!ldsomap)
> return 0;
>
> - newobj = XCNEW (struct so_list);
> - old_chain = make_cleanup (xfree, newobj);
> - lm_info_svr4 *li = lm_info_read (ldsomap);
> - newobj->lm_info = li;
> - make_cleanup (xfree, newobj->lm_info);
> + std::unique_ptr<lm_info_svr4> li (lm_info_read (ldsomap));
I think it's clearer to use the assignment operator in that case:
std::unique_ptr<lm_info_svr4> li = lm_info_read (ldsomap);
Simon
next prev parent reply other threads:[~2018-03-30 19:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 4:24 [RFA 0/2] more cleanup removal Tom Tromey
2018-03-28 4:24 ` [RFA 1/2] Change target_read_string to use unique_xmalloc_ptr Tom Tromey
2018-03-30 5:28 ` Simon Marchi
2018-03-28 4:24 ` [RFA 2/2] Remove some clanups from solib-svr4.c Tom Tromey
2018-03-30 5:47 ` Simon Marchi
2018-03-30 19:04 ` Tom Tromey
2018-03-30 19:12 ` Simon Marchi [this message]
2018-03-30 19:18 ` Tom Tromey
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=79a2885c006051d0975ef5422d469ceb@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.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