Re: [PATCH 1/1] gdb: Fix arrays of variable length strings for FORTRAN

[Tom Tromey <tom@tromey.com>]

>> >> case TYPE_CODE_ARRAY:
>> >> +    case TYPE_CODE_STRING:
>> >> c_value_print_array (val, stream, recurse, options);
>> >> break;
>> 
Andrew> I don't understand what part this change plays in this patch.  I can
Andrew> see below how you're now creating values with TYPE_CODE_STRING instead
Andrew> of TYPE_CODE_ARRAY, but then I'd expect these to be covered by the
Andrew> existing handling of TYPE_CODE_STRING in
Andrew> f_language::value_print_inner.

>> I wonder if this should go in generic_value_print instead.

Andrew> generic_val_print_array doesn't print arrays of character type things
Andrew> as a string, so I think having this change in c_value_print_inner
Andrew> makes sense.

In this case, though, the patch is adding new treatment for
TYPE_CODE_STRING.  It seems to me that it would make sense to handle
this in the generic code.

Andrew> I did wonder if we should _also_ change generic_val_print though, as
Andrew> this would catch any language that wasn't Fortran, C, or C++ that
Andrew> called into generic_val_print and didn't already handle
Andrew> TYPE_CODE_STRING.

Yeah.

Andrew> However, that's only Modula2 and Pascal, both of which already handle
Andrew> TYPE_CODE_ARRAY and do something similar to C's print character types
Andrew> as a string, which leads me to think that maybe both of these
Andrew> languages should be handling TYPE_CODE_STRING as an alias for
Andrew> TYPE_CODE_ARRAY.

That would be fine as well.  It's still often useful for the generic
code to handle a case, because users can language-switch and wind up
printing an "unexpected" type via the "wrong" language, like:

(gdb) print value_of_type_code_string
(gdb) set lang c
(gdb) print $

Andrew> I'm also tempted to say that the Modula2 and Pascal changes are
Andrew> optional, as that seems like an edge case (user debugging Fortran code
Andrew> with the language forced to one of those two choices).

This should do something sensible when possible.  It doesn't always --
sometimes the languages have special code to decode things.  But, that
seems like a not very good way to do it to me; better instead to unify
the type system and then the fallback code can do something useful, even
if not fully correct for the current language (which isn't always
possible).

One question for me is, if TYPE_CODE_STRING is a string, can we avoid
language-specific code for it at all?  And just always handle it in the
generic code.

Tom