Re: curses vs non-ASCII

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Thu, Nov 19, 2015 at 04:01:42PM -0500, Mouse wrote:
> >> Well, it surprised me.  It is a regression as compared to 1.4T and
> >> 4.0.1, each of which works exactly the way I want here, with 0x80
> >> through 0xff all being treated as printables.  (Test program below.)
> > Well, that would be a serious bug and I am somewhat surprised if
> > netbsd-4 really behaved like that -- it doesn't match any of the
> > classic character sets.
> 
> It does in my tests.  I no longer have any completely stock 4.0.1
> systems, but I did just now check, and none of my local patches affect
> lib/libcurses, lib/libc/citrus, or lib/libc/locale.  I have only a few
> patches that affect lib/libc at all; none of them look likely to be
> relevant here.  (Five touch lib/libc only for manpages,  One adds
> _malloc_options.  One spiffs up setmode(3).  Four hack on glob(3).  And
> that is the whole list.)

Please make sure we are talking about the same things. It seems like old
curses simply throw whatever it got onto the screen. It did not check
for printable. That's what isprint(3) is for. The pre-wchar versions
didn't check for valid input at all, so naturally all characters would
pass through. Terminals are not supposed to print something for
non-printable characters, it is arguably a bug if they do.

> >> However, I do have reason to think mbrtowc is part of the
> >> precipitate here; specifically, by default, the 5.2 curses not only
> >> drops the non-ASCII octet, but sometimes eats the following octet as
> >> well.  Even without any setlocale().
> > Test case, please.
> 
> Hm!
> 
> I know I saw cases where one ASCII-range character was disappearing,
> and it looked to me as though it was always happening immediately
> following a non-ASCII character.  But I can't make it happen in a test
> program, and I no longer have the source for the version I saw it in.
> I'll have to experiment and see if I can recreate it.  If I can build a
> test case I'll post it.

Just trying to rule out accidently setting UTF8, which would show this
kind of behavior...

Joerg