Subject: Re: bug#21124: 'invalid-mb-seq-UMR' test fails

From: Jim Meyering <[email-masked]>
Date: Thu, 30 Jul 2015 09:56:29 -0700

On Wed, Jul 29, 2015 at 5:02 PM, Assaf Gordon <[email-masked]> wrote:
> Hello,
>
> On Mon, Jul 27, 2015 at 10:31:21PM -0700, Jim Meyering wrote:
>>
>> On Thu, Jul 23, 2015 at 2:47 PM, Assaf Gordon <[email-masked]>
>> wrote:
>>>
>>> With sed from git (4.2.2.89-e387), I get one test failure in
>>> 'invalid-mb-seq-UMR' (log attached).
>>>
>>> The error seem to be:
>>> ===
>>> +valgrind --quiet --error-exitcode=1 sed -e 's/a/b\U\xb2c/' in
>>
>>
>> What versions of valgrind and gcc are you using -- and what type of
>> system?
>
>
> I'm using:
>
>     $ uname -a
>     Linux XXX 3.13.0-58-generic #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015
> x86_64 GNU/Linux
>     $ gcc --version
>     gcc (GCC) 5.2.0
>     $ valgrind --version
>     valgrind-3.10.0.SVN
>
> But, looking deeper I've noticed the test uses a locale which is not
> available on my system (ja_JP.eucJP).
> Here are couple of related tests:
>
>     # (the extra commit .90 is the ununsed-code removal
>     #  http://lists.gnu.org/archive/html/bug-sed/2015-07/msg00005.html)
>     $ ./sed/sed --version | head -n1
>     ./sed/sed (GNU sed) 4.2.2.90-9f3b
>
>     # The locale I don't have produces 'ff'
>     $ echo a | LC_ALL=ja_JP.eucJP ./sed/sed -e 's/a/b\U\xb2c/' | od -tx1a
>     0000000  62  ff  43  0a
>               b del   C  nl
>     0000004
>
>     # A locale I do have works as expected
>     $ echo a | LC_ALL=ja_JP.utf8 ./sed/sed -e 's/a/b\U\xb2c/' | od -tx1a
>     0000000  62  43  0a
>               b   C  nl
>     0000003
>
> For comparison, an older 'sed':
>
>     $ sed --version
>     sed (GNU sed) 4.2.2
>
>     # Existing locale
>     $ echo a | LC_ALL=ja_JP.utf8 sed -e 's/a/b\U\xb2c/' | od -tx1a
>     0000000  62  00  43  0a
>               b nul   C  nl
>     0000004
>
>     # non-existing locale
>     $ echo a | LC_ALL=ja_JP.eucJP sed -e 's/a/b\U\xb2c/' | od -tx1a
>     0000000  62  ff  43  0a
>               b del   C  nl
>     0000004
>
> So perhaps the fix is simply to skip the test if the locale doesn't exist.

Thank you for investigating.

We already have a configure-time test to detect the desired
type of locale. The attached patch makes this test use
the configure-set variable, $LOCALE_JA, and skip the test
when its value is "none". Does that work for you?
From 51dc57ab9cdb6a5470cd2c516d9bbfdda1828b50 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[email-masked]>
Date: Thu, 30 Jul 2015 09:47:25 -0700
Subject: [PATCH] tests: avoid false-failure on system with no ja_JP.eucJP
 locale

* testsuite/invalid-mb-seq-UMR.sh: Use the configure-detected
locale name, $LOCALE_JA, rather than hard-coding ja_JP.eucJP.
If the required type of locale was not detected, then skip
this test. Reported by Assaf Gordon in http://bugs.gnu.org/21124
---
 testsuite/invalid-mb-seq-UMR.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/testsuite/invalid-mb-seq-UMR.sh b/testsuite/invalid-mb-seq-UMR.sh
index d74b5be..f631e24 100755
--- a/testsuite/invalid-mb-seq-UMR.sh
+++ b/testsuite/invalid-mb-seq-UMR.sh
@@ -21,9 +21,11 @@ print_ver_ sed

 require_valgrind_

+test "$LOCALE_JA" = none && skip_ found no Japanese EUC locale
+
 echo a > in || framework_failure_
 echo bC > exp || framework_failure_
-LC_ALL=ja_JP.eucJP valgrind --quiet --error-exitcode=1 \
+LC_ALL=$LOCALE_JA valgrind --quiet --error-exitcode=1 \
   sed -e 's/a/b\U\xb2c/' in > out 2> err || fail=1

 # Work around a bug in CentOS 5.10's valgrind
-- 
2.3.7