From: Doug Evans <dje@google.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches <gdb-patches@sourceware.org>,
Joel Brobecker <brobecker@adacore.com>,
Sterling Augustine <saugustine@google.com>
Subject: Re: [PATCH] PR 16286: Reading python value as string beyond declared size
Date: Tue, 03 Dec 2013 23:01:00 -0000 [thread overview]
Message-ID: <CADPb22SFRk9ZVkaF1HPt_mQcsqxpBFhvtrdD7GK5e6_Vx7K7ug@mail.gmail.com> (raw)
In-Reply-To: <529E3F10.6030607@redhat.com>
On Tue, Dec 3, 2013 at 12:29 PM, Pedro Alves <palves@redhat.com> wrote:
> On 12/02/2013 11:14 PM, Doug Evans wrote:
>> + if (*length > 0)
>> + fetchlimit = UINT_MAX;
>
> Shouldn't this be:
>
> if (*length > 0)
> fetchlimit = *length;
>
> ? That is, if the caller specified a limit, why do we do over it?
read_string will take min (len, fetchlimit), and I saw no value in
passing fetchlimit = *length.
> Couldn't this new check be merge above where we compute
> fetchlimit to begin with? With the comment there adjusted to
> something like:
>
> + /* If have an explicit requested length, use that as fetchlimit.
> + Otherwise, if we know the size of the array, we can use it as
> + a limit on the number of characters to be fetched. */
I want to keep fetchlimit and *length separate at this point.
They have different meanings/purposes.
> BTW, it looks like the not_lval/lval_internalvar path can
> blindly read beyond the value's contents buffer, if *length
> is bigger than the value's contents buffer size:
>
> /* If the string lives in GDB's memory instead of the inferior's,
> then we just need to copy it to BUFFER. Also, since such strings
> are arrays with known size, FETCHLIMIT will hold the size of the
> array. */
> if ((VALUE_LVAL (value) == not_lval
> || VALUE_LVAL (value) == lval_internalvar)
> && fetchlimit != UINT_MAX)
> {
> int i;
> const gdb_byte *contents = value_contents (value);
>
> /* If a length is specified, use that. */
> if (*length >= 0)
> i = *length;
> ^^^^^^^^^^^^^
> else
> /* Otherwise, look for a null character. */
> for (i = 0; i < fetchlimit; i++)
> if (extract_unsigned_integer (contents + i * width,
> width, byte_order) == 0)
> break;
>
> /* I is now either a user-defined length, the number of non-null
> characters, or FETCHLIMIT. */
> *length = i * width;
> *buffer = xmalloc (*length);
> memcpy (*buffer, contents, *length);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It didn't look right to me either, but I was leaving digging deeper
for another pass.
next prev parent reply other threads:[~2013-12-03 23:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-02 23:15 Doug Evans
2013-12-03 20:29 ` Pedro Alves
2013-12-03 23:01 ` Doug Evans [this message]
2013-12-04 11:47 ` Pedro Alves
2013-12-11 0:25 ` Doug Evans
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=CADPb22SFRk9ZVkaF1HPt_mQcsqxpBFhvtrdD7GK5e6_Vx7K7ug@mail.gmail.com \
--to=dje@google.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=saugustine@google.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