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 20:04:24 +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> <49D65557.email@example.com>
Phil Muldoon wrote:
Replying to myself, but Thiago mentioned something on irc that I did not
read until later. c_get_string uses read_string which does take a length
argument. The logic just has to be altered to make sure it (the length
argument) gets there. So that's a happy relief.
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've no idea on the other language string readers. I'll look into them.