Re: [PATCH, doc RFA] Fix lazy string type docs

[Doug Evans <dje@google.com>]

On Thu, Nov 3, 2016 at 12:03 PM, Doug Evans <dje@google.com> wrote:
> 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.

Ok, an audit of all internal uses that I can find of lazy_string->type
use the type as an element of the string.

E.g.: py-pretty-print.c:print_children has:

          gdbpy_extract_lazy_string (py_v, &addr, &type, &length, &encoding);

          local_opts.addressprint = 0;
          val_print_string (type, encoding, addr, (int) length, stream,
                            &local_opts);

val_print_string takes a string element type as the first arg.

I think the right thing to do here is go with the posted patch (after
doc is ok).
And I'll post another patch to fix char[] handling (I'll file a pr for
that too, assuming my search fu can't find an existing one).
Plus I have another patch after that to fix another aspect of lazy
string handling.