This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [python] StdStringPrinter misleading?
El dom, 29-03-2009 a las 12:10 -0600, Tom Tromey escribiÃ:
> >>>>> "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?
I was referring to substituting a simple <value obj>.string(encoding)
call by all that code there. But now I see that a single string method
call can't be expected to work in this case.
> Most of the new code is just decoding the internal representation of
> std::string.
Right, my mistake.
> 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.
So one can't assign a std::string value to a convenience variable? or it
means that parts of it will be in the inferior anyway?
> 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.
Right. I agree with you. From reading the patch I thought that
self.val['_M_dataplus']['_M_p'] would be all that one needs to read to
get the string. Brainfart, I guess.
So perhaps having an optional length argument to the string method could
indeed make life easier in cases like this.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center