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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 39970@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 39970
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch