Re: curses vs non-ASCII

[Brett Lymn <blymn%internode.on.net@localhost>]

On Fri, Nov 20, 2015 at 09:24:44AM -0500, Mouse wrote:
> >> At a guess I would say that you have stumbled across a character
> >> sequence that happens to be valid multibyte character but I haven't
> >> looked closely.  What does mbrtowc(3) do with that sequence?
> 
> It currently appears it's not a multibyte issue.  On my morning
> commute I wrote a small test program (below) and it makes me think
> mbrtowc is not at fault here.  Its output on my test system is
> 
> offset 0: byte count 1, wc 0xb7
> offset 1: byte count 1, wc 0x20
> offset 2: byte count 1, wc 0x20
> offset 3: byte count 1, wc 0x41
> offset 4: byte count 1, wc 0x62
> offset 5: byte count 1, wc 0x62
> offset 6: byte count 1, wc 0x61
> offset 7: byte count 1, wc 0x3a
> offset 8: byte count 1, wc 0x20
> offset 9: byte count 1, wc 0x54
> 
> This then forces me to wonder what is.  It seems to me that, regardless
> of whether it's considered printable, curses should not misbehave: if
> it's printable, it should have been printed; if not, it should have
> been dropped.  This leads me to suspect this is actually a curses bug.
> This might also explain why Martin Husemann did not see any
> misbehaviour under current - current may well have a curses without
> that (putative) bug.
> 

That may well be.  I think that parts of refresh have been refactored
since 5.  It should be simple to get the libcurses from -current and
build it under 5, there are very few system dependencies.

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.