guix commands broken on Azerbaijani 'az_AZ' and Turkish 'tr_TR' locales

  • Open
  • quality assurance status badge
Details
4 participants
  • Ludovic Courtès
  • Maxim Cournoyer
  • pelzflorian (Florian Pelz)
  • Taylan Kammer
Owner
unassigned
Submitted by
pelzflorian (Florian Pelz)
Severity
normal
P
P
pelzflorian (Florian Pelz) wrote on 7 Mar 2020 13:00
(address . bug-guix@gnu.org)
20200307120052.ocwzphlvemvmb2ts@pelzflorian.localdomain
After running

export LC_ALL=tr_TR.utf8

many important Guix commands like 'guix environment', 'guix install'
and 'guix pull' fail.

$ guix environment --ad-hoc hello
Backtrace:
1 (primitive-load "/home/florian/.config/guix/current/bin…")
In guix/ui.scm:
1826:12 0 (run-guix-command _ . _)

guix/ui.scm:1826:12: In procedure run-guix-command:
In procedure string-length: Wrong type argument in position 1 (expecting string): #f


Running guix via ./pre-inst-env gives a more useful backtrace. The
reason is that in guix/store.scm

(use-modules (ice-9 regex))
(regexp-exec (make-regexp "^/gnu/store/([0-9a-df-np-sv-z]{32})-([^/]+)$")
"/gnu/store/bv9py3f2dsa5iw0aijqjv9zxwprcy1nb-fontconfig-2.13.1.drv")

evaluates to #f in Turkish, possibly because of the presence of
dotless i (?) in the range.

The attached patch fixes the issue by including i explicitly, but I
believe enumerating all of [0-9abcdfghijklmnpqrsvwxyz] explicitly
might be more future-proof.

Shall I push the patch modified to list all letters in
[0-9abcdfghijklmnpqrsvwxyz] explicitly? Numbers too? I suppose there
is no downside to listing all without ranges.

I wonder what else is affected; the installer maybe? I have not
tested yet.

Regards,
Florian
From 4445284e9fd40b3e271fa7b511d2856c03c8ccfb Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Sat, 7 Mar 2020 11:38:59 +0100
Subject: [PATCH] store: Fix many guix commands failing on some locales.

At least 'guix environment', 'guix install' and 'guix pull'
on 'az_AZ.utf8' and 'tr_TR.utf8' are affected.

* guix/store.scm (store-regexp*): Avoid dependence on locale.
---
guix/store.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Toggle diff (15 lines)
diff --git a/guix/store.scm b/guix/store.scm
index f99fa581a8..a1d9713c24 100644
--- a/guix/store.scm
+++ b/guix/store.scm
@@ -1949,7 +1949,7 @@ valid inputs."
(mlambda (store)
"Return a regexp matching a file in STORE."
(make-regexp (string-append "^" (regexp-quote store)
- "/([0-9a-df-np-sv-z]{32})-([^/]+)$"))))
+ "/([0-9a-df-hij-np-sv-z]{32})-([^/]+)$"))))
(define (store-path-package-name path)
"Return the package name part of PATH, a file name in the store."
--
2.25.0
P
P
pelzflorian (Florian Pelz) wrote on 7 Mar 2020 16:20
(address . 39970@debbugs.gnu.org)
20200307152003.myj7jkjthokbmark@pelzflorian.localdomain
On Sat, Mar 07, 2020 at 01:00:52PM +0100, pelzflorian (Florian Pelz) wrote:
Toggle quote (11 lines)
> Running guix via ./pre-inst-env gives a more useful backtrace. The
> reason is that in guix/store.scm
>
> (use-modules (ice-9 regex))
> (regexp-exec (make-regexp "^/gnu/store/([0-9a-df-np-sv-z]{32})-([^/]+)$")
> "/gnu/store/bv9py3f2dsa5iw0aijqjv9zxwprcy1nb-fontconfig-2.13.1.drv")
>
> evaluates to #f in Turkish, possibly because of the presence of
> dotless i (?) in the range.
>

Actually it seems the issue is that i is missing from the range [a-z]
? and ? are missing as well, as are non-Turkish letters like ä that
are included when using the en_US.utf8 locale, even though they are no
English letters either.

(use-modules (ice-9 regex))
(regexp-exec (make-regexp "^([a-z]+)$")
"iyiyim")

fails.

But running a glibc C program

florian@florianmacbook ~$ cat iyiyim.c
#include <regex.h>
#include <stdio.h>
#define STR "iyiyim"
int main (int argc,
char** argv)
{
regex_t only_letters;
int r = regcomp (&only_letters, "[a-z]", 0);
if (r != 0)
printf ("This error does not happen.\n");
r = regexec (&only_letters, STR, 0, NULL, 0);
if (r == 0)
printf ("The string " STR " matched!\n");
else
printf ("No match for " STR ".\n");
}
florian@florianmacbook ~$ gcc -o iyiyim iyiyim.c
florian@florianmacbook ~$ LANG=tr_TR.utf8 ./iyiyim
The string iyiyim matched!

succeeds on tr_TR.utf8 and en_US.utf8 locales (and a native Turkish
speaker confirmed to me ?i should be in the alphabet right after h).
Maybe this is a bug in Guile, somehow?

Toggle quote (5 lines)
> […]
> I wonder what else is affected; the installer maybe? I have not
> tested yet.
>

I checked; the graphical installer appears unaffected, but the issue
appears on the installed system.

Regards,
Florian
P
P
pelzflorian (Florian Pelz) wrote on 8 Mar 2020 08:08
(address . 39970@debbugs.gnu.org)
20200308070804.ylpb5yrwpgbc3p3w@pelzflorian.localdomain
This seems similar to https://bugs.gnu.org/35785. I think
enumerating all characters explicitly is a similar fix, whether or not
there is a bug in Guile.

Regards,
Florian
L
L
Ludovic Courtès wrote on 9 Mar 2020 18:02
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 39970@debbugs.gnu.org)
8736ah1mxb.fsf@gnu.org
Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (2 lines)
> This seems similar to https://bugs.gnu.org/35785.

Yes, same story.

Toggle quote (3 lines)
> I think enumerating all characters explicitly is a similar fix,
> whether or not there is a bug in Guile.

To me it’s not a bug in Guile, but simply the fact that regexps, as
implemented by the C library, are locale-dependent.

The patch you proposed looks good to me, though perhaps we could
explicitly list all the alphabet in the regexp?

A better option is to reimplement ‘store-path-package-name’ in a way
similar to ‘store-path-hash-part’, as in commit
35eb77b09d957019b2437e7681bd88013d67d3cd.

Thoughts?

Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 12 Mar 2020 12:02
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 39970@debbugs.gnu.org)
20200312110206.2hsinzejnmcefmot@pelzflorian.localdomain
On Mon, Mar 09, 2020 at 06:02:40PM +0100, Ludovic Courtès wrote:
Toggle quote (4 lines)
> To me it’s not a bug in Guile, but simply the fact that regexps, as
> implemented by the C library, are locale-dependent.
>

(use-modules (ice-9 regex))
(regexp-exec (make-regexp "^([a-z]+)$")
"iyiyim")
⇒ #f

Guile’s behavior that i is not among [a-z] has been confirmed as
unexpected by a natively Turkish friend of mine. It is different from
the behavior of current glibc:

florian@florianmacbook ~$ cat iyiyim.c
#include <regex.h>
#include <stdio.h>
#include <stdlib.h>
#define STR "iyiy?m"
int main (int argc,
char** argv)
{
regex_t only_letters;
int r = regcomp (&only_letters, "[a-z]+", REG_EXTENDED);
if (r != 0)
printf ("This error does not happen.\n");
r = regexec (&only_letters, STR, 1, malloc (sizeof (regmatch_t)), 0);
if (r == 0)
printf ("The string " STR " matched!\n");
else
printf ("No match for " STR ".\n");
}
florian@florianmacbook ~$ gcc -o iyiyim iyiyim.c
florian@florianmacbook ~$ LANG=tr_TR.utf8 ./iyiyim
The string iyiy?m matched!

Apparently Guile uses a bundled regular expression library rather than
glibc. I can try making Guile use a newer GNUlib for its regular
expressions, maybe that helps. Shall I file a separate bug for Guile?

Toggle quote (7 lines)
> The patch you proposed looks good to me, though perhaps we could
> explicitly list all the alphabet in the regexp?
>
> A better option is to reimplement ‘store-path-package-name’ in a way
> similar to ‘store-path-hash-part’, as in commit
> 35eb77b09d957019b2437e7681bd88013d67d3cd.

I suppose it would be better to cache the compiled regexp. What is
this mcached syntax inside (guix store)? Or do I use Scheme’s 'delay'
and 'force' for caching?

The attached patch fixes the regexp. Shall I push the attached patch
and then try making it cache the compiled regexp or do you still
prefer an implementation without regexps? Why would not using a
regexp be better?

Regards,
Florian
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Thu, 12 Mar 2020 11:08:16 +0100
Subject: [PATCH] store: Fix many guix commands failing on some locales.

Fixes bug #39970 (see: https://bugs.gnu.org/39970).

At least 'guix environment', 'guix install' and 'guix pull'
on 'az_AZ.utf8' and 'tr_TR.utf8' are affected.

* guix/store.scm (store-regexp*): Avoid dependence on locale.
---
guix/store.scm | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

Toggle diff (16 lines)
diff --git a/guix/store.scm b/guix/store.scm
index f99fa581a8..82d7403bb6 100644
--- a/guix/store.scm
+++ b/guix/store.scm
@@ -1949,7 +1949,8 @@ valid inputs."
(mlambda (store)
"Return a regexp matching a file in STORE."
(make-regexp (string-append "^" (regexp-quote store)
- "/([0-9a-df-np-sv-z]{32})-([^/]+)$"))))
+ "\
+/([0-9abcdfghijklmnpqrsvwxyz]{32})-([^/]+)$"))))
(define (store-path-package-name path)
"Return the package name part of PATH, a file name in the store."
--
2.25.1
L
L
Ludovic Courtès wrote on 12 Mar 2020 17:05
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 39970@debbugs.gnu.org)
874kutsgmx.fsf@gnu.org
Hi Florian,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (23 lines)
> On Mon, Mar 09, 2020 at 06:02:40PM +0100, Ludovic Courtès wrote:
>> To me it’s not a bug in Guile, but simply the fact that regexps, as
>> implemented by the C library, are locale-dependent.
>>
>
> (use-modules (ice-9 regex))
> (regexp-exec (make-regexp "^([a-z]+)$")
> "iyiyim")
> ⇒ #f
>
> Guile’s behavior that i is not among [a-z] has been confirmed as
> unexpected by a natively Turkish friend of mine. It is different from
> the behavior of current glibc:
>
> florian@florianmacbook ~$ cat iyiyim.c
> #include <regex.h>
> #include <stdio.h>
> #include <stdlib.h>
> #define STR "iyiy?m"
> int main (int argc,
> char** argv)
> {

You’re seeing a different behavior because you forgot a:

setlocale (LC_ALL, "");

call here.

Toggle quote (11 lines)
>> The patch you proposed looks good to me, though perhaps we could
>> explicitly list all the alphabet in the regexp?
>>
>> A better option is to reimplement ‘store-path-package-name’ in a way
>> similar to ‘store-path-hash-part’, as in commit
>> 35eb77b09d957019b2437e7681bd88013d67d3cd.
>
> I suppose it would be better to cache the compiled regexp. What is
> this mcached syntax inside (guix store)? Or do I use Scheme’s 'delay'
> and 'force' for caching?

I lean towards avoiding regexps altogether, as I wrote above.

WDYT?

Toggle quote (5 lines)
> The attached patch fixes the regexp. Shall I push the attached patch
> and then try making it cache the compiled regexp or do you still
> prefer an implementation without regexps? Why would not using a
> regexp be better?

It reduces reliance on libc, reduces complexity, and performs better as
noted in the commit log of 35eb77b09d957019b2437e7681bd88013d67d3cd.

Thanks,
Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 17 Mar 2020 10:44
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 39970@debbugs.gnu.org)
20200317094443.cnajoi4yuzvxaafe@pelzflorian.localdomain
On Thu, Mar 12, 2020 at 05:05:26PM +0100, Ludovic Court�s wrote:
Toggle quote (6 lines)
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> > Why would not using a regexp be better?
>
> It reduces reliance on libc, reduces complexity, and performs better as
> noted in the commit log of 35eb77b09d957019b2437e7681bd88013d67d3cd.

Thank you for your wisdom. I hope the attached patch is OK.

`LC_ALL=en_US.utf8 make check` is mostly fine (except tests/pack.scm,
which also failed before).

Manual testing of `./pre-inst-env guix environment` works.

`LC_ALL=tr_TR.utf8 make check` is still very unhappy though.
There are many failures. I will continue to investigate later today.

Regards,
Florian
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Thu, 12 Mar 2020 11:08:16 +0100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH] store: Fix many guix commands failing on some locales.

Partly fixes bug #39970 (see: https://bugs.gnu.org/39970).

At least 'guix environment', 'guix install' and 'guix pull'
on 'az_AZ.utf8' and 'tr_TR.utf8' were affected.

* guix/store.scm (store-path-hash-part): Move base path detection to ...
(store-path-base): ... this new exported procedure.
(store-path-package-name): Use it instead of locale-dependent regexps.
(store-regexp*): Remove.
---
guix/store.scm | 32 +++++++++++++++-----------------
1 file changed, 15 insertions(+), 17 deletions(-)

Toggle diff (73 lines)
diff --git a/guix/store.scm b/guix/store.scm
index f99fa581a8..5465204f5f 100644
--- a/guix/store.scm
+++ b/guix/store.scm
@@ -2,6 +2,7 @@
;;; Copyright � 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Court�s <ludo@gnu.org>
;;; Copyright � 2018 Jan Nieuwenhuizen <janneke@gnu.org>
;;; Copyright � 2019 Mathieu Othacehe <m.othacehe@gmail.com>
+;;; Copyright � 2020 Florian Pelz <pelzflorian@pelzflorian.de>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -43,7 +44,6 @@
#:use-module (srfi srfi-35)
#:use-module (srfi srfi-39)
#:use-module (ice-9 match)
- #:use-module (ice-9 regex)
#:use-module (ice-9 vlist)
#:use-module (ice-9 popen)
#:use-module (ice-9 threads)
@@ -172,6 +172,7 @@
store-path?
direct-store-path?
derivation-path?
+ store-path-base
store-path-package-name
store-path-hash-part
direct-store-path
@@ -1943,29 +1944,26 @@ valid inputs."
"Return #t if PATH is a derivation path."
(and (store-path? path) (string-suffix? ".drv" path)))
-(define store-regexp*
- ;; The substituter makes repeated calls to 'store-path-hash-part', hence
- ;; this optimization.
- (mlambda (store)
- "Return a regexp matching a file in STORE."
- (make-regexp (string-append "^" (regexp-quote store)
- "/([0-9a-df-np-sv-z]{32})-([^/]+)$"))))
+(define (store-path-base path)
+ "Return the base path of a path in the store."
+ (and (string-prefix? (%store-prefix) path)
+ (let ((base (string-drop path (+ 1 (string-length (%store-prefix))))))
+ (and (> (string-length base) 33)
+ (not (string-index base #\/))
+ base))))
(define (store-path-package-name path)
"Return the package name part of PATH, a file name in the store."
- (let ((path-rx (store-regexp* (%store-prefix))))
- (and=> (regexp-exec path-rx path)
- (cut match:substring <> 2))))
+ (let ((base (store-path-base path)))
+ (string-drop base (+ 32 1)))) ;32 hash part + 1 hyphen
(define (store-path-hash-part path)
"Return the hash part of PATH as a base32 string, or #f if PATH is not a
syntactically valid store path."
- (and (string-prefix? (%store-prefix) path)
- (let ((base (string-drop path (+ 1 (string-length (%store-prefix))))))
- (and (> (string-length base) 33)
- (let ((hash (string-take base 32)))
- (and (string-every %nix-base32-charset hash)
- hash))))))
+ (let* ((base (store-path-base path))
+ (hash (string-take base 32)))
+ (and (string-every %nix-base32-charset hash)
+ hash)))
(define (derivation-log-file drv)
"Return the build log file for DRV, a derivation file name, or #f if it
--
2.25.1
L
L
Ludovic Courtès wrote on 17 Mar 2020 22:20
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 39970@debbugs.gnu.org)
87wo7ibrwe.fsf@gnu.org
Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (14 lines)
> On Thu, Mar 12, 2020 at 05:05:26PM +0100, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
>> > Why would not using a regexp be better?
>>
>> It reduces reliance on libc, reduces complexity, and performs better as
>> noted in the commit log of 35eb77b09d957019b2437e7681bd88013d67d3cd.
>
> Thank you for your wisdom. I hope the attached patch is OK.
>
> `LC_ALL=en_US.utf8 make check` is mostly fine (except tests/pack.scm,
> which also failed before).
>
> Manual testing of `./pre-inst-env guix environment` works.

Good!

Toggle quote (3 lines)
> `LC_ALL=tr_TR.utf8 make check` is still very unhappy though.
> There are many failures. I will continue to investigate later today.

OK.

Toggle quote (8 lines)
> From: Florian Pelz <pelzflorian@pelzflorian.de>
> Date: Thu, 12 Mar 2020 11:08:16 +0100
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> Subject: [PATCH] store: Fix many guix commands failing on some locales.
>
> Partly fixes bug #39970 (see: https://bugs.gnu.org/39970).

I’d just write:


Concise, clear, greppable. :-)

Toggle quote (8 lines)
> At least 'guix environment', 'guix install' and 'guix pull'
> on 'az_AZ.utf8' and 'tr_TR.utf8' were affected.
>
> * guix/store.scm (store-path-hash-part): Move base path detection to ...
> (store-path-base): ... this new exported procedure.
> (store-path-package-name): Use it instead of locale-dependent regexps.
> (store-regexp*): Remove.

LGTM, thank you!

Ludo’.
P
P
pelzflorian (Florian Pelz) wrote on 18 Mar 2020 07:47
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 39970@debbugs.gnu.org)
20200318064712.iycghze5nnr7q777@pelzflorian.localdomain
On Tue, Mar 17, 2020 at 10:20:01PM +0100, Ludovic Courtès wrote:
Toggle quote (6 lines)
> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> > `LC_ALL=tr_TR.utf8 make check` is still very unhappy though.
> > There are many failures. I will continue to investigate later today.
>
> OK.

The tests fail to many other uses of [a-z] in regexps. I will look;
for e.g. guix/import/cran.scm

(if (string-match "^[A-Za-z][^ :]+:( |\n|$)" line)
…)

it would be easier and clearer to just list [a-z] explicitly:


Toggle quote (2 lines)
> LGTM, thank you!

:) Pushed as 771c5e155d7862ed91a5d503eecc00c1db1150ad.

Regards,
Florian
L
L
Ludovic Courtès wrote on 18 Mar 2020 09:40
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . 39970@debbugs.gnu.org)
87a74eawew.fsf@gnu.org
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

Toggle quote (15 lines)
> On Tue, Mar 17, 2020 at 10:20:01PM +0100, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
>> > `LC_ALL=tr_TR.utf8 make check` is still very unhappy though.
>> > There are many failures. I will continue to investigate later today.
>>
>> OK.
>
> The tests fail to many other uses of [a-z] in regexps. I will look;
> for e.g. guix/import/cran.scm
>
> (if (string-match "^[A-Za-z][^ :]+:( |\n|$)" line)
> …)
>
> it would be easier and clearer to just list [a-z] explicitly:

Yes, agreed.

It would be nice if ‘string-match’ & co. could take an optional locale
object (info "(guile) i18n Introduction") but that’s not the case
currently.

Thanks,
Ludo’.
M
M
Maxim Cournoyer wrote on 5 May 2021 06:47
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
875yzxlrcp.fsf@gmail.com
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

Toggle quote (20 lines)
> On Tue, Mar 17, 2020 at 10:20:01PM +0100, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
>> > `LC_ALL=tr_TR.utf8 make check` is still very unhappy though.
>> > There are many failures. I will continue to investigate later today.
>>
>> OK.
>
> The tests fail to many other uses of [a-z] in regexps. I will look;
> for e.g. guix/import/cran.scm
>
> (if (string-match "^[A-Za-z][^ :]+:( |\n|$)" line)
> …)
>
> it would be easier and clearer to just list [a-z] explicitly:
>
>
>> LGTM, thank you!
>
> :) Pushed as 771c5e155d7862ed91a5d503eecc00c1db1150ad.

Closing.

Thank you,

Maxim
Closed
T
T
Taylan Kammer wrote on 5 May 2021 09:04
(address . 39970@debbugs.gnu.org)
e3929738-588c-e27a-69b4-bb405f536e75@gmail.com
On 12.03.2020 12:02, pelzflorian (Florian Pelz) wrote:
Toggle quote (31 lines)
>
> Guile’s behavior that i is not among [a-z] has been confirmed as
> unexpected by a natively Turkish friend of mine. It is different from
> the behavior of current glibc:
>
> florian@florianmacbook ~$ cat iyiyim.c
> #include <regex.h>
> #include <stdio.h>
> #include <stdlib.h>
> #define STR "iyiy?m"
> int main (int argc,
> char** argv)
> {
> regex_t only_letters;
> int r = regcomp (&only_letters, "[a-z]+", REG_EXTENDED);
> if (r != 0)
> printf ("This error does not happen.\n");
> r = regexec (&only_letters, STR, 1, malloc (sizeof (regmatch_t)), 0);
> if (r == 0)
> printf ("The string " STR " matched!\n");
> else
> printf ("No match for " STR ".\n");
> }
> florian@florianmacbook ~$ gcc -o iyiyim iyiyim.c
> florian@florianmacbook ~$ LANG=tr_TR.utf8 ./iyiyim
> The string iyiy?m matched!
>
> Apparently Guile uses a bundled regular expression library rather than
> glibc. I can try making Guile use a newer GNUlib for its regular
> expressions, maybe that helps. Shall I file a separate bug for Guile?
>
Also native Turkish speaker here, and yeah that seems like a clear bug.

By the way, Turkish doesn't have q, w, or x. So if [a-z] is interpreted
by locale, it would fail to match those letters. I suppose that doesn't
matter for the patch you guys used but it might have been part of the
original problem.

The dotless lowercase i / dotted uppercase I mostly bites programmers in
case conversion. The uppercase of i is ? and the lowercase of I is ?.
There was even an exploit in GitHub related to this:



- Taylan
P
P
pelzflorian (Florian Pelz) wrote on 5 May 2021 11:22
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
20210505092248.i3qfrteekhkwhd3y@pelzflorian.localdomain
On Wed, May 05, 2021 at 12:47:02AM -0400, Maxim Cournoyer wrote:
Toggle quote (6 lines)
> Closing.
>
> Thank you,
>
> Maxim

Sorry for forgetting about this bug. The above

LC_ALL=tr_TR.utf8 make check TESTS=tests/cran.scm

is *not* fixed, but I won’t take the time to really understand and fix
the few remaining troubles, I think. Possibly libc bug
issue.

Regards,
Florian
Closed
?