Re: [python] StdStringPrinter misleading?

[Phil Muldoon <pmuldoon at redhat dot com>]

Tom Tromey wrote:
> Thiago> So perhaps having an optional length argument to the string
> Thiago> method could indeed make life easier in cases like this.
>
> I was thinking about this problem a bit more this afternoon.  It
> occurred to me that counted strings are reasonably common in user
> code, so we'd want some way to express that, even if we put
> language-specific information (like std::string) into the gdb core.
> Whether this way is value.string or gdb.read_memory, I don't know.
> I lean toward string, but if you have a preference...
>   
I hacked a bit on this today. I altered valpy_string to take an optional 
length integer argument for a string. To conclude the thread it would 
solve the embedded null issue with (quoting Tom's patch):

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

And an additional len parameter to string:

return self.val['_M_dataplus']['_M_p'].string(encoding, len)

So I coded in the relevant optional argument logic into the Python 
sections of the code, and I then passed this length argument to 
LA_GET_STRING. This does the usual language lookups and (in my example 
case) resolves to c_get_string. I found to my dismay that with this 
particular language's get_string implementation I cannot pass a length 
parameter that it will use. The length parameter passed to it has the 
length of the string "read" written to it. In c_get_string case the 
amount read is to the first \0 or if an array, the bounds of that array 
if that is met first. So we'd have to rewrite c_get_string to pay 
attention to length if it has a value, and ignore nulls if length_read < 
length_specified. This makes me a little nervous.

I thought about just reading the length parameter as it is, and setting 
the fetchlimit to that. And still allowing the language get_string to 
write the amount actually read. That would seem the simplest case at 
least in the C derivation. But as every use of this function before now 
has only expected length to be written, I am worried that this will lead 
to issues when an uninitialized length variable is passed in the 
c_read_string.

Any opinions?

Regards

Phil