Re: ls is broken for non-C locales due to libxo

On 2015-06-16 23:23, Marcel Moolenaar wrote:
> 
>> On Jun 16, 2015, at 7:42 PM, Andrey Chernov <ache_at_freebsd.org> wrote:
>>
>> On 17.06.2015 5:18, Andrey Chernov wrote:
>>> Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo.
>>>
>>
>> I mean ls -l. To be precise, for 8bit non-C locales at least:
>> ls -lt: skip date column and eat filename with even single 8bit
>> character inside.
>> ls -l: just eat filename as above.
> 
> Date/time is fixed. I don’t know how to reproduce the filename
> problem, so make sure sources are up-to-date and if still a
> problem, provide me with a way to reproduce.
> 
> Thanks,
> 
> --
> Marcel Moolenaar
> marcel_at_xcllnt.net
> 

Simple reproduction:

env LANG=ru_RU.KOI8-R ./ls -l --libxo warn
total 200
ls: invalid UTF-8 character: c9/2
-rw-r--r--  1 allan  allan    315  Makefile
ls: invalid UTF-8 character: c9/2
-rw-r--r--  1 allan  allan    405  Makefile.depend
ls: invalid UTF-8 character: cd/2
-rw-r--r--  1 allan  allan   4922  cmp.c
ls: invalid UTF-8 character: c9/2
-rw-r--r--  1 allan  allan   4096  cmp.o
ls: invalid UTF-8 character: c9/2
-rw-r--r--  1 allan  allan   2987  extern.h
ls: invalid UTF-8 character: c9/2
-rwxr-xr-x  1 allan  allan  38934  ls
ls: invalid UTF-8 character: c9/2

It seems like the problem is that xo_utf8_to_wc_len() doesn't know how
to deal with 8 bit characters that are not UTF-8. If the highest bit is
set, but it is not UTF-8, libxo pukes.

-- 
Allan Jude