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

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Tom Tromey <tom@tromey.com> [2021-08-23 14:54:53 -0600]:

> >>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
> 
> >> 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.

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

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

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

Given that language_defn::value_print_inner actually calls
c_value_print_inner, rather than generic_val_print, I do wonder if
some/all of c_value_print_inner could be moved into generic_val_print,
though that's clearly out of scope of this patch.

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

Thanks,
Andrew