This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [python] StdStringPrinter misleading?

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?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]