From: Tom Tromey <tom@tromey.com>
To: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
Cc: Christian Biesinger <cbiesinger@google.com>
Subject: Re: [PATCH] Change some arguments to gdb::string_view instead of name+len
Date: Mon, 30 Sep 2019 14:28:00 -0000 [thread overview]
Message-ID: <87zhilamf5.fsf@tromey.com> (raw)
In-Reply-To: <20190929053440.144834-1-cbiesinger@google.com> (Christian Biesinger via gdb-patches's message of "Sun, 29 Sep 2019 00:34:40 -0500")
>>>>> "Christian" == Christian Biesinger via gdb-patches <gdb-patches@sourceware.org> writes:
Christian> Just some code cleanup. This change has a few benefits:
Christian> - Shorter argument list in the functions
Christian> - If the caller needs to calculate the string, they no longer
Christian> need to explicitly call strlen
Christian> - It is easy to pass std::string to this (done in one place
Christian> currently)
Christian> This also updates a couple of places that were passing 0/1 to
Christian> a bool parameter.
Thanks for doing this. I think it is a nice cleanup.
Christian> -minimal_symbol_reader::record_full (const char *name, int name_len,
[...]
Christian> if (name[0] == get_symbol_leading_char (m_objfile->obfd))
Christian> {
Christian> - ++name;
Christian> - --name_len;
Christian> + name = gdb::string_view (name.data() + 1, name.length () - 1);
This could probably use the substr method.
Christian> if (symtab_create_debug >= 2)
Christian> printf_unfiltered ("Recording minsym: %-21s %18s %4d %s\n",
Christian> - mst_str (ms_type), hex_string (address), section, name);
Christian> + mst_str (ms_type), hex_string (address), section,
Christian> + name.data ());
This part made me hesitate a bit, because it seems to be at odds with
the idea that an arbitrary string view can be passed in -- for all we
know the string isn't \0-terminated, and this will cause bad behavior.
On the other hand, this error already existed, and is only used for
logging.
Maybe safest is just to transform it to a std::string here?
Tom
next prev parent reply other threads:[~2019-09-30 14:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-29 5:34 Christian Biesinger via gdb-patches
2019-09-30 14:28 ` Tom Tromey [this message]
2019-09-30 14:38 ` Pedro Alves
2019-09-30 16:23 ` Tom Tromey
2019-09-30 19:33 ` Christian Biesinger via gdb-patches
2019-09-30 19:33 ` [PATCH v2] " Christian Biesinger via gdb-patches
2019-09-30 19:46 ` [PATCH v3] " Christian Biesinger via gdb-patches
2019-09-30 20:02 ` [PATCH v4] " Christian Biesinger via gdb-patches
2019-10-01 17:18 ` Tom Tromey
2019-10-01 17:26 ` Christian Biesinger via gdb-patches
2019-10-01 17:26 ` [PATCH] " Christian Biesinger via gdb-patches
2019-10-01 17:33 ` Christian Biesinger via gdb-patches
2019-10-01 18:23 ` Pedro Alves
2019-10-01 18:27 ` Christian Biesinger via gdb-patches
2019-10-01 18:31 ` Christian Biesinger via gdb-patches
2019-10-01 19:10 ` Pedro Alves
2019-10-01 19:30 ` Christian Biesinger via gdb-patches
2019-10-02 14:45 ` Pedro Alves
2019-10-02 18:44 ` Christian Biesinger via gdb-patches
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=87zhilamf5.fsf@tromey.com \
--to=tom@tromey.com \
--cc=cbiesinger@google.com \
--cc=gdb-patches@sourceware.org \
/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