This is the mail archive of the
mailing list for the Archer project.
Re: [python][patch] Preserve string length, and embedded-nulls inpretty-print string emission.
Tom Tromey wrote:
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 and I talked a little about this on irc, so I'll replicate the
The TYPE_LENGTH (value_type (value)) works great, thanks. But there are
some further issues. In the pretty-printing code there are three
branches of logic:
- if it has a "string" display hint, use LA_PRINT_STRING;
- if it does not have a hint, but it is string, use fputs_filtered;
- for all other value cases, use common_val_print.
Two of these cases require a definite identification that the value
holds a string. I guess in the first case you could rely on the hint,
but the second case is troublesome. As far as I know there is no
convenient universal way to determine if the contents of a value are a
string. Using: TYPE_CODE (value_type (value)) will either return
TYPE_CODE_STRING, or TYPE_CODE_ARRAY (or PTR) depending on how the
string is constructed. If it returns ARRAY, how do we determine that it
is a string? In c-valprint there is a private convenience routine
called: textual_element_type that tests for this, but it does not work
with wide strings, and is very C string specific. So that is no good.
The last time we know that it is a string "for sure" is in
convert_value_from_python which converts a PyObject into a gdb value.
Right now in my patch, if it is a string the length is returned via
out-parameter in: convert_value_from_python. This is, in effect, a flag.
But it now seems less than optimal to design an out-parameter around one
troublesome type. Should convert_value_from_python write an
out-parameter with TYPE_CODE_* that matches the value type (and in the
case of a string, always return TYPE_CODE_STRING regardless of how the
string is constructed?)
Or are there other ideas out there?