From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from jupiter.monnerat.net (jupiter.monnerat.net [46.226.111.226]) by sourceware.org (Postfix) with ESMTPS id C6E2D3858C55 for ; Sat, 8 Oct 2022 00:12:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C6E2D3858C55 Received: from [192.168.0.128] ([192.168.0.128]) by jupiter.monnerat.net (8.14.8/8.14.8) with ESMTP id 2980C2qk009531 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=OK); Sat, 8 Oct 2022 02:12:08 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 jupiter.monnerat.net 2980C2qk009531 Message-ID: <0a978271-3085-8bf3-f5fd-6a0b3f9f3ea2@monnerat.net> Date: Sat, 8 Oct 2022 02:12:02 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Subject: Re: [PATCH] gdb: add UTF16/UTF32 target charsets in phony_iconv To: Tom Tromey , Patrick Monnerat via Gdb-patches References: <20221002140010.106238-1-patrick@monnerat.net> <87k05bs8c5.fsf@tromey.com> Content-Language: en-US From: Patrick Monnerat In-Reply-To: <87k05bs8c5.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org 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: , X-List-Received-Date: Sat, 08 Oct 2022 00:12:52 -0000 On 10/7/22 22:10, Tom Tromey wrote: >>>>>> "Patrick" == Patrick Monnerat via Gdb-patches writes: Many thanks for your review and remarks. > Patrick> Function phony_iconv is substituted to the system-supplied iconv on > Patrick> platforms where the latter is deficient. > > I sort of hate to improve the phony iconv, but I get why one might want > to. Me too! In fact, I even hate the idea of phony_iconv: this is just a workaround for a particular case of unreliable external component. Conversions to UTF-32 were probably not needed/mandatory when phony_iconv was implemented. This is not the case anymore and a true workaround should now support them. > > Patrick> Conditonal statements decide when the substitution occurs. This > Patrick> currently enables it for mingw (wchar_t is not UTF-32) even when the > Patrick> system-supplied iconv is suitable for gdb use. > > I don't recall the outcome from this, but is there no way to improve gdb > to use this iconv? If it truly works well enough then it seems like it > would be the better approach. There is a fuzzy source comment about an iconv problem in Solaris. Your bugzilla comment https://sourceware.org/bugzilla/show_bug.cgi?id=29315#c2 also goes in this direction: however we have no details about what the problem is, if we should still support it and/or if there are other systems affected by such an iconv problem. Conditionals enabling phony_iconv rely on ISO-10646 availability (32-bit wchar_t?), Haible's implementation of iconv and/or btowc availability, but not on a particular OS (see gdb_wchar.h). This is very hard to establish a relation between the conditionals and what the implementor wanted to target. In the absence of further info, this patch goes the safe way and probably resolves UTF-32 problems on some platforms. Ideally, phony_iconv should be removed if the problem has not to be supported anymore. Else, conditionals targeting the faulty cases (but what are they?) rather than the working ones would be preferable. If we have to keep phony_iconv, it should be able to support conversions to UTF-32 anyway. Please note I had the intention to determine the Solaris problem and tried to install the last available OpenSolaris (dated 2009) in a VM without success: I gave up. Patrick