From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA 3/3] Make extract_arg return a std::string
Date: Mon, 11 Sep 2017 19:52:00 -0000 [thread overview]
Message-ID: <31794437bc5e56865f80cc72691899a4@polymtl.ca> (raw)
In-Reply-To: <20170911003325.3765-4-tom@tromey.com>
On 2017-09-11 02:33, Tom Tromey wrote:
> Change extract_arg to return a std::string and fix up all the users.
> I think string is mildly better than unique_xmalloc_ptr<char>, when
> possible, because it provides a more robust API.
I agree, for strings we allocate dynamically ourselves, it makes sense
to use std::string. For dynamically allocated strings coming from
external APIs we use, then unique_xmalloc_ptr<char> make sense, since it
doesn't require doing a copy. For things that are always
constant/literal strings, the const char *.
> I changed the error messages emitted from find_location_by_number to
> avoid either writing to a string or an extra allocation; this can be
> changed but I thought that the new message was not any less clear.
> You can see an example in the testsuite patch.
I made almost the same patch (although unpolished):
https://github.com/simark/binutils-gdb/commit/afac80f165a016ca2089169efe7dd266aa8a0ddc
and made pretty much the same choices, so that's fine with me. I just
have some small comments, the patch is ok to me with those fixed.
> diff --git a/gdb/break-catch-sig.c b/gdb/break-catch-sig.c
> index 805084f..237dbaa 100644
> --- a/gdb/break-catch-sig.c
> +++ b/gdb/break-catch-sig.c
> @@ -343,12 +343,12 @@ catch_signal_split_args (char *arg, bool
> *catch_all)
> gdb_signal signal_number;
> char *endptr;
>
> - gdb::unique_xmalloc_ptr<char> one_arg (extract_arg (&arg));
> - if (one_arg == NULL)
> + std::string one_arg = extract_arg (&arg);
> + if (one_arg.empty ())
> break;
>
> /* Check for the special flag "all". */
> - if (strcmp (one_arg.get (), "all") == 0)
> + if (strcmp (one_arg.c_str (), "all") == 0)
one_arg == "all"
> diff --git a/gdb/cli/cli-utils.h b/gdb/cli/cli-utils.h
> index 038ddad..c17b4dd 100644
> --- a/gdb/cli/cli-utils.h
> +++ b/gdb/cli/cli-utils.h
> @@ -149,17 +149,14 @@ remove_trailing_whitespace (const char *start,
> char *s)
> }
>
> /* A helper function to extract an argument from *ARG. An argument is
> - delimited by whitespace. The return value is either NULL if no
> - argument was found, or an xmalloc'd string. */
> + delimited by whitespace. The return value is either empty if no
"either" does not make sense in the new sentence.
> + argument was found. */
>
> -extern char *extract_arg (char **arg);
> +extern std::string extract_arg (char **arg);
>
> -/* A const-correct version of "extract_arg".
> +/* A const-correct version of "extract_arg". */
It's a bit funny to refer to extract_arg when this function is also
named extract_arg. What about: "A const-correct version of the above."
?
> @@ -553,16 +556,14 @@ exists_probe_with_pops (VEC (bound_probe_s)
> *probes,
> [PROBE [OBJNAME]]] from the provided string STR. */
>
> static void
> -parse_probe_linespec (const char *str, char **provider,
> - char **probe_name, char **objname)
> +parse_probe_linespec (const char *str, std::string *provider,
> + std::string *probe_name, std::string *objname)
> {
> - *probe_name = *objname = NULL;
Here, I would keep the clearing of probe_name and objname (calling
.clear ()), just in case a user of parse_probe_linespec decides to
re-use string objects. It then couldn't know if parse_probe_linespec
set the value, or if it's the old value.
Simon
next prev parent reply other threads:[~2017-09-11 19:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-11 0:33 [RFA 0/3] preparation for command constification; cleanup removal Tom Tromey
2017-09-11 0:33 ` [RFA 1/3] Rename _const functions to use overloading instead Tom Tromey
2017-09-11 19:16 ` Simon Marchi
2017-09-11 0:33 ` [RFA 2/3] Constify language_enum Tom Tromey
2017-09-11 19:17 ` Simon Marchi
2017-09-11 0:33 ` [RFA 3/3] Make extract_arg return a std::string Tom Tromey
2017-09-11 19:52 ` Simon Marchi [this message]
2017-09-11 21:43 ` 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=31794437bc5e56865f80cc72691899a4@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