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

["Ijaz, Abdul B" <abdul.b.ijaz@intel.com>]

Hi Tom,

Reminder to the last query. If it is fine can we merge this patch since it is not breaking existing functionality.  Thanks

Best Regards
Abdul Basit

-----Original Message-----
From: Ijaz, Abdul B <abdul.b.ijaz@intel.com> 
Sent: Wednesday, December 29, 2021 12:31 PM
To: Tom Tromey <tom@tromey.com>; Andrew Burgess <andrew.burgess@embecosm.com>
Cc: abdul.b.ijaz <abijaz@ecsmtp.iul.intel.com>; gdb-patches@sourceware.org
Subject: RE: [PATCH 1/1] gdb: Fix arrays of variable length strings for FORTRAN

Hi Tom and Andrew,

I do not feel so comfortable to modify generic code and my break things because of not having full overview. Will it be fine to merge this change if it is fine and not breaking anything or how shall we proceed on this. Thanks

Best Regards
Abdul Basit 

-----Original Message-----
From: Tom Tromey <tom@tromey.com>
Sent: Friday, August 27, 2021 7:03 PM
To: Andrew Burgess <andrew.burgess@embecosm.com>
Cc: Tom Tromey <tom@tromey.com>; Ijaz, Abdul B <abdul.b.ijaz@intel.com>; abdul.b.ijaz <abijaz@ecsmtp.iul.intel.com>; gdb-patches@sourceware.org
Subject: Re: [PATCH 1/1] gdb: Fix arrays of variable length strings for FORTRAN

>> >> 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 
Andrew> can see below how you're now creating values with 
Andrew> TYPE_CODE_STRING instead of TYPE_CODE_ARRAY, but then I'd expect 
Andrew> these to be covered by the existing handling of TYPE_CODE_STRING 
Andrew> in 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 
Andrew> things as a string, so I think having this change in 
Andrew> c_value_print_inner 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 
Andrew> though, as this would catch any language that wasn't Fortran, C, 
Andrew> or C++ that called into generic_val_print and didn't already 
Andrew> handle TYPE_CODE_STRING.

Yeah.

Andrew> However, that's only Modula2 and Pascal, both of which already 
Andrew> handle TYPE_CODE_ARRAY and do something similar to C's print 
Andrew> character types as a string, which leads me to think that maybe 
Andrew> both of these languages should be handling TYPE_CODE_STRING as 
Andrew> an alias for 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 
Andrew> Fortran code 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
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928