From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 24157385C301 for ; Sun, 13 Nov 2022 20:29:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24157385C301 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1ouJc5-0008PK-GZ for gcc-patches@gcc.gnu.org; Sun, 13 Nov 2022 21:29:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH 3/5] Fortran: Narrow return types [PR78798] Date: Sun, 13 Nov 2022 21:29:50 +0100 Message-ID: <638282cb-c299-e022-3296-da1382a0f509@gmx.de> References: <20221112234543.95441-1-aldot@gcc.gnu.org> <20221112234543.95441-4-aldot@gcc.gnu.org> <20221113113938.555d4a06@nbbrfq> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Content-Language: en-US In-Reply-To: <20221113113938.555d4a06@nbbrfq> Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20221113202950.qwR9mllSvY6FomG5UsZ4iNb1cdnSRQ5PIdlstEXAJXc@z> Am 13.11.22 um 11:39 schrieb Bernhard Reutner-Fischer via Gcc-patches: > On Sun, 13 Nov 2022 12:13:26 +0200 > Janne Blomqvist wrote: > >> On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran >> wrote: >>> --- a/gcc/fortran/arith.cc >>> +++ b/gcc/fortran/arith.cc >>> @@ -1135,7 +1135,7 @@ compare_complex (gfc_expr *op1, gfc_expr *op2) >>> strings. We return -1 for a < b, 0 for a == b and 1 for a > b. >>> We use the processor's default collating sequence. */ >>> >>> -int >>> +signed char >>> gfc_compare_string (gfc_expr *a, gfc_expr *b) >>> { >>> size_t len, alen, blen, i; >>> @@ -1162,7 +1162,7 @@ gfc_compare_string (gfc_expr *a, gfc_expr *b) >>> } >> >> Hmm, really? PR 78798 mentions changing int to bool, where >> appropriate, which I think is uncontroversial, but this? > > Well we could leave this or all spots alone where a bool is > insufficient, if you prefer. > > In the case of gfc_compare_string, the only user is simplify which only > looks at ge/gt/le/lt 0 My reading of the mentioned PR is that there is a fundamental disagreement with the subject: Bug 78798 - [cleanup] some int-valued functions should be bool I see that as an issue of (a minor lack of) conciseness; it is *not* about narrowing. Replacing "int" by "signed char" adds confusion and makes code less understandable, so I would oppose it, as we don't solve a real problem and rather add confusion.