Re: [python] StdStringPrinter misleading?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

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

Which part are you referring to?

Most of the new code is just decoding the internal representation of
std::string.

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

Yeah, it may not.  That is a general problem with C++ printers,
because the typical C++ object has a bunch of pointers to other
objects, which probably will not live in values.

Thiago> It seems that python_string_to_host_string should return the string
Thiago> length, not just the char *. I think that's what you refer to, right?

Yeah.

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

Yes, that might work.

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

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

Do you mean it should know by knowing the layout of std::string?
I think that would unduly tie gdb to a particular libstdc++.
The nice thing about doing the work in Python is that the details can
be maintained alongside the libstdc++ to which they refer.

Thiago> What is your impression of gdb.read_memory, after using it?

Works great!

Tom