This is the mail archive of the
mailing list for the Archer project.
Re: [python] StdStringPrinter misleading?
>>>>> "Thiago" == Thiago Jung Bauermann <email@example.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
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?
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?