[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ncurses-5.7-20090530.patch.gz

From: Thomas Dickey
Subject: Re: ncurses-5.7-20090530.patch.gz
Date: Wed, 3 Jun 2009 07:06:37 -0400 (EDT)

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]