From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZDGxJ/gaKWGQXwAAWB0awg (envelope-from ) for ; Fri, 27 Aug 2021 13:03:52 -0400 Received: by simark.ca (Postfix, from userid 112) id 928021EE1B; Fri, 27 Aug 2021 13:03:52 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,RDNS_DYNAMIC,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B0E401EDEE for ; Fri, 27 Aug 2021 13:03:51 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3A9F63857828 for ; Fri, 27 Aug 2021 17:03:51 +0000 (GMT) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.178]) by sourceware.org (Postfix) with ESMTPS id 449473858D34 for ; Fri, 27 Aug 2021 17:03:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 449473858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tromey.com Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 69E70969390 for ; Fri, 27 Aug 2021 12:02:56 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id JfFomHG2VjSwzJfFomdvOs; Fri, 27 Aug 2021 12:02:56 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ODyoDNDgMviRhr7oyBS77RhD0DbCaalwRbthgMbS7+o=; b=Qa1SEOYAgJlHGoJGfuvh9hNV/9 CVpIEhyFuk56It2/JWXSIQPli2kpLMPY6R0JiBj+tL/k9cFnE4eRlcd5HD+5T1BcBCEjSnLx5JjN5 Lbtn80h2IzS9TuEvwny0MDd0U; Received: from 97-122-86-84.hlrn.qwest.net ([97.122.86.84]:40696 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mJfFn-001B9Q-Vs; Fri, 27 Aug 2021 11:02:56 -0600 From: Tom Tromey To: Andrew Burgess Subject: Re: [PATCH 1/1] gdb: Fix arrays of variable length strings for FORTRAN References: <20210820110638.26648-1-abdul.b.ijaz@intel.com> <20210820110638.26648-2-abdul.b.ijaz@intel.com> <20210820155247.GA2581@embecosm.com> <87zgt7990i.fsf@tromey.com> <20210825085636.GG2581@embecosm.com> X-Attribution: Tom Date: Fri, 27 Aug 2021 11:02:55 -0600 In-Reply-To: <20210825085636.GG2581@embecosm.com> (Andrew Burgess's message of "Wed, 25 Aug 2021 09:56:36 +0100") Message-ID: <87ilzqom68.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.86.84 X-Source-L: No X-Exim-ID: 1mJfFn-001B9Q-Vs X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-86-84.hlrn.qwest.net (murgatroyd) [97.122.86.84]:40696 X-Source-Auth: tom+tromey.com X-Email-Count: 4 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: abdul.b.ijaz@intel.com, Tom Tromey , gdb-patches@sourceware.org, "abdul.b.ijaz" Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" >> >> 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