Re: [python] StdStringPrinter misleading?

[Thiago Jung Bauermann <bauerman at br dot ibm dot com>]

El vie, 27-03-2009 a las 19:35 -0600, Tom Tromey escribiÃ:
> >>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:
> 
> Paul> std::string could contain embedded NUL characters, and current
> Paul> StdStringPrinter hides this (not that the raw printing is any better):
> 
> The appended almost does it.

I'd prefer if Value.string did the job, like in the current version of
the StdStringPrinter. But I didn't dig into this to find out if it's
possible.

Your patch looks like a big workaround, perhaps we can save people from
having to do stuff like this when reading strings from the inferior?

Also, I don't htink it would work with gdb-side values.

> However, it doesn't work because
> pretty_print_one_value loses the length information.  I think this
> should not be too hard to deal with... either Phil or I will implement
> this soon.

It seems that python_string_to_host_string should return the string
length, not just the char *. I think that's what you refer to, right?
Ditto for python_string_to_target_string, of course.

This may trigger a chain of changes to make all callers properly use the
string length instead of assuming that char * strings are always
null-terminated. This is the direction all of GDB should go eventually,
by the way. Except code dealing specifically with the C language, of
course.

I believe this comment in pretty_print_one_value is outdated:

 /* If we just call convert_value_from_python for this
    type, we won't know who owns the result.  For this
    one case we need to copy the resulting value.  */

Jim Blandy fixed convert_value_from_python to always return a
caller-owned result.

Because of this, pretty_print_one_value can now probably just call
convert_value_from_python in all cases and be done with it. Perhaps
doing this will side-step the issue with python_string_to_host_string,
and allow pretty_print_one_value to always return a struct value instead
of returning a char * sometimes? Would this change fix the problem found
by Paul?

As a side note, I think that convert_value_from_python has a bug in that
it uses python_string_to_target_string. IIUC Python values should be
assumed to be in the host encoding and representation. Perhaps there are
other places with this same bug, I'll have to check that.

> If we go with this patch, we'll need to push the membuf stuff upstream.

I intend to push the membuf stuff upstream for 7.0. But it depends on
implementing the Inferior API first, since read_memory and friends are a
per-inferior thing.

> Perhaps a better plan would be to add a length argument to Value.string.
> Thiago, what do you think?

I think that Value.string should "just know" what the string length is,
adding a length argument sounds like a workaround to me, I'd rather
avoid having to do that.

> +        ptr = self.val['_M_dataplus']['_M_p']
> +        realtype = self.val.type().unqualified().strip_typedefs()
> +        reptype = gdb.Type(str(realtype) + '::_Rep').pointer()
> +        header = ptr.cast(reptype) - 1
> +        len = header.dereference()['_M_length']
> +        charwidth = ptr.type().target().sizeof()

Wow, I think this is a good example of how powerful the value and type
classes turned out to be. I think we're heading in the right direction
here. :-)

Congratulations on the type class.

> +        data = gdb.read_memory (long (ptr), long (len) * charwidth)
> +        return unicode (data, encoding)

What is your impression of gdb.read_memory, after using it? I think it's
effective and "Pythonic", but I'd like to see if others have an opinion.
I think up to now, I was the only one who actually used it.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center