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

[Jim Meyering]

On Wed, Jul 29, 2015 at 5:02 PM, Assaf Gordon <address@hidden> 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 <address@hidden>
>> 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?

0001-tests-avoid-false-failure-on-system-with-no-ja_JP.eu.patch
Description: Text Data