This is the mail archive of the
mailing list for the Archer project.
Re: [python] StdStringPrinter misleading?
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Thiago Jung Bauermann <bauerman at br dot ibm dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, archer at sourceware dot org
- Date: Fri, 03 Apr 2009 19:28:39 +0100
- Subject: Re: [python] StdStringPrinter misleading?
- References: <20090328002208.083A33A6BE4@localhost> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
Tom Tromey wrote:
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):
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...
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