Re: ncurses-5.7-20090530.patch.gz

[Thomas Dickey]

On Wed, 3 Jun 2009, Clemens Ladisch wrote:

> Thomas Dickey wrote:
> > On Wed, 3 Jun 2009, Clemens Ladisch wrote:
> > > 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").
>
> So this is why unctrl() calls iswprint()?

yes... It should only be _calling_ iswprint if there is a locale set:

                if ((check >= 160)
                 && (check < 256)
                 && ((sp != 0)
                  && ((sp->_legacy_coding > 0)
                       ^^^ (this is true if there's no locale set, so
                            evaluation of the expression stops here)

                   || (sp->_legacy_coding == 0
                       && (isprint(check) || iswprint(check))))))
                        result = unctrl_blob + unctrl_c1[check - 128];
> > If the locale is set, ncurses follows that (or should - barring bug
> > reports).
>
> Well, this is the point of my bug report; unctrl() _always_ calls both
> isprint() and iswprint(), so it uses the union of the printable
> characters of both the current locale and of ISO 8859-1.
>
> It should avoid calling iswprint() once another locale has been set, but
> I don't see how this could be detected: the return value of setlocale()
> is not portable, and ASCII and UTF-8 are indistinguishable as far as
> isprint() is concerned.
>
>
> Best regards,
> Clemens

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