This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [python][patch] Preserve string length, and embedded-nulls in pretty-print string emission.
- From: Tom Tromey <tromey at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Wed, 27 May 2009 14:22:39 -0600
- Subject: Re: [python][patch] Preserve string length, and embedded-nulls in pretty-print string emission.
- References: <4A1709CB.7030200@redhat.com> <m3octev48j.fsf@fleche.redhat.com><4A1D8544.2030006@redhat.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
Phil> This function returns a struct value. If that value contains a
Phil> string with embedded nulls, is there a way to determine the size
Phil> of the "gdb_byte *contents"?
I think: TYPE_LENGTH (value_type (value))
That should get you the size in bytes.
You may need to convert to characters, I'm not sure.
Tom> Why do we need LA_GET_STRING here? Aren't the string contents already
Tom> in the value?
Phil> I'll look at this a little more closely. But I use this to extract a
Phil> string with embedded nulls with a concrete length. Do I misread your
Phil> thoughts here? Or are you suggesting we just pass in value->contents
Phil> to LA_PRINT_STRING?
Yeah, I think that would be the way to go.
Tom> A test relying on std::string is not very robust -- std::string may
Tom> change over time, breaking the test. Instead, it is better to write
Tom> custom test code and a printer to match. That way, we control the
Tom> implementation.
Phil> Ok thanks for the pointer. Can you please elaborate a bit more?
Suppose std::string changes in some future libstdc++. In that case,
we would have a printer in the test suite that would be incorrect.
This would lead to test failures, even though the gdb code under test
is actually functioning perfectly.
So, rather than using std::string, just write a simple counted string
object of some kind and use it in the test.
Tom