Re: ncurses-5.7-20090530.patch.gz

[Thomas Dickey]

On Wed, 3 Jun 2009, Clemens Ladisch wrote:

> Thomas Dickey wrote:
> > On Tue, 2 Jun 2009, Clemens Ladisch wrote:
> > > The remaining problem is just that unctrl() returns a wrong string for
> > > any characters that would be printable if interpreted as a wide
> > > character.
> > >
> > > For example, in UTF-8, 0xff is not a valid character, but the Unicode
> > > character U+00ff would be printable, so unctrl() returns "\377" instead
> > > of the correct "~?".
> >
> > I'll have to review that in detail (evening/weekend...).  However reading
> > the patch, it seems that it does not take into account that an application
> > must have initialized the locale before ncurses will stop using the legacy
> > encoding.
>
> I don't quite understand your last sentence.  As far as I understand
> the curses specification, ncurses should _never_ stop using the legacy
> encoding because any locale could use an encoding that has non-printable
> characters above 127.  For example, UTF-8 uses the bytes 128..253 for
> multi-byte sequences, so none of these are printable.

Not exactly.  If the locale is unset, technically only POSIX (0-127) is 
recommended.  However, since 1997 (before locale support on Linux was 
anything but vaporware), ncurses has interpreted that case as ISO-8859-1 
(hence "legacy").

If the locale is set, ncurses follows that (or should - barring bug 
reports).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net