This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Add la_getstr member to language_defn
- From: Tom Tromey <tromey at redhat dot com>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Mon, 24 Nov 2008 09:44:14 -0700
- Subject: Re: [RFA] Add la_getstr member to language_defn
- References: <email@example.com>
- Reply-to: tromey at redhat dot com
>>>>> "Thiago" == Thiago Jung Bauermann <firstname.lastname@example.org> writes:
Thiago> Each language supported by GDB can provide a way to read
Thiago> strings from a value by suppling its version of the
Thiago> function. I implemented it for C, in c_getstr.
Thanks. For those not tracking the Python branch, this functionality
is important to many scripts.
Thiago> * language.h (language_dfn): Add la_getstr member.
Thiago> (LA_GET_STRING): New macro.
A nit: the macro is called LA_GET_STRING, but the field is la_getstr.
How about la_get_string for the field instead?
Thiago> + int (*la_getstr) (struct value *value, gdb_byte **buffer, int *length);
I was thinking about writing this function for Java, sort of as a
proof of the API. One oddity here is that a String there has a fixed
encoding, which may or may not be the same as the target charset (and
in any case, is not convertible using the charset.c code).
One idea for fixing this is to let this new method optionally return
an encoding. That way a language implementation could fill in this
info if it is known. The C implementation would simply do nothing
What do you think?