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 <blomqvist.ja...@gmail.com> wrote:
On Sun, Nov 13, 2022 at 1:47 AM Bernhard Reutner-Fischer via Fortran
<fortran@gcc.gnu.org> 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.
