From: Doug Evans <dje@google.com>
To: gdb-patches <gdb-patches@sourceware.org>,
Eli Zaretskii <eliz@gnu.org>, Phil Muldoon <pmuldoon@redhat.com>
Subject: Re: [PATCH, doc RFA] Fix lazy string type docs
Date: Thu, 03 Nov 2016 19:04:00 -0000 [thread overview]
Message-ID: <CADPb22QvOHADZuv1x4UJ4x28k0_jFEqoatgcaJYdX5RwJUaiTQ@mail.gmail.com> (raw)
In-Reply-To: <94eb2c1121f421b06405406923b6@google.com>
On Thu, Nov 3, 2016 at 10:46 AM, Doug Evans <dje@google.com> wrote:
> Hi.
>
> I was trying to understand a problem I was having with python lazy strings.
> It turns out the docs are wrong, and the "type" attribute of a lazy
> string is the character type, not a pointer to the character's type.
... Unless the thing we're making a lazy string out of is an array
instead of a pointer.
const char* foo = "Dave";
const char bar[] = "No, man, I'm Dave.";
(gdb) py print gdb.parse_and_eval("foo").lazy_string().type
const char
(gdb) py print gdb.parse_and_eval("bar").lazy_string().type
const char [19]
I don't have a strong opinion on what the correct answer is, but there
is certainly a bug here.
Phil, do you remember why this code exists in valpy_lazy_string():
if (TYPE_CODE (value_type (value)) == TYPE_CODE_PTR)
value = value_ind (value);
[lazy string support went in in commit be759fcf]
I kinda like the type of the lazy string version of a char array still
being a char array.
OTOH, when I look at the definition of a lazy string, recording the
character type makes more sense
(to me anyway: e.g., length would be redundant for the case where type
is a char array)
typedef struct {
PyObject_HEAD
/* Holds the address of the lazy string. */
CORE_ADDR address;
/* Holds the encoding that will be applied to the string
when the string is printed by GDB. If the encoding is set
to None then GDB will select the most appropriate
encoding when the sting is printed. */
char *encoding;
/* Holds the length of the string in characters. If the
length is -1, then the string will be fetched and encoded up to
the first null of appropriate width. */
long length;
/* This attribute holds the type that is represented by the lazy
string's type. */
struct type *type;
} lazy_string_object;
To fix this bug we're going to have to break one or the other, or add
a knob (bleah) to control the old, broken, behaviour.
Or mark the "type" LazyString attribute as broken/deprecated and
provide a new attribute with correct behaviour.
Opinions?
next prev parent reply other threads:[~2016-11-03 19:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-03 17:46 Doug Evans
2016-11-03 18:21 ` Eli Zaretskii
2016-11-03 18:36 ` Doug Evans
[not found] ` <CADPb22QnnuHuG+sC=rg5HUJP2L_m1P_J7TTFLv0H-KDd6tON=A@mail.gmail.com>
2016-11-03 19:07 ` Eli Zaretskii
2016-11-03 23:55 ` Doug Evans
2016-11-04 7:31 ` Eli Zaretskii
2016-11-03 19:04 ` Doug Evans [this message]
2016-11-03 21:20 ` André Pönitz
2016-11-04 0:01 ` Doug Evans
2016-11-04 17:53 ` Doug Evans
2016-11-04 19:20 ` Phil Muldoon
2016-11-04 19:29 ` 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=CADPb22QvOHADZuv1x4UJ4x28k0_jFEqoatgcaJYdX5RwJUaiTQ@mail.gmail.com \
--to=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=pmuldoon@redhat.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