Re: COLOR_PAIRS on Fedora 29

[Bryan Christ]

Okay.  Thanks for the clarification.

On Thu, Jan 17, 2019 at 3:28 PM Thomas Dickey <address@hidden> wrote:

On Thu, Jan 17, 2019 at 12:15:59PM -0600, Bryan Christ wrote:
> It seems like that Fedora 29, Cosmic, etc which have terminfo entries with
> pairs set to something greater than 0x7FFF are assuming that you'll be
> using interfaces that aren't portable.  In other words, init_pair() can't
> take an unsigned short (I've tried and it definitely doesn't like it).

yes - you can only do this using an extension, because the existing
standard prevents other interpretations.

> Therefore, it means that init_extended_pair() must be used but that's an
> ncurses extension.  Maybe I'm missing something.  Do other implementations
> offer these interfaces or is this just a case of *shrug* for portability?

If it's popular enough, NetBSD will copy the extension.

https://invisible-island.net/ncurses/ncurses-netbsd.html
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libcurses/?>

But they haven't noticed it yet.  The usual route for them noticing
is its use in a program in pkgsrc (ports).

PDCurses doesn't do this - there's some hack in Bill Gray's fork to support
RGB if chtype is 64-bits, but it doesn't integrate with color pairs.

https://github.com/wmcbrine/PDCurses
https://github.com/Bill-Gray/PDCurses

For others... I've not seen any recent development for AIX or HPUX.
Solaris "new" code seems to be integrating "open source", but with
a sizable (5+ years) time delay.

> On Wed, Jan 16, 2019 at 7:42 PM Thomas Dickey <address@hidden> wrote:
>
> > On Wed, Jan 16, 2019 at 05:43:00PM -0600, Bryan Christ wrote:
> > > Timothy,
> > >
> > > Thanks for that explanation.  It sounds like the right thing to do is to
> > > switch over to an unsigned short and handle the nuances of values greater
> > > than 0x7FFF.
> >
> > not quite - extended color pairs are an "int" (usually bigger than a
> > "short").
> > (the same applies for extended color values)
> >
> > > On Wed, Jan 16, 2019 at 5:18 PM Timothy Allen <address@hidden>
> > wrote:
> > >
> > > > On Wed, 2019-01-16 at 10:20 -0600, Bryan Christ wrote:
> > > > > I'm debugging an issue on Fedora 29.  The terminfo value for pairs on
> > > > > xterm-256color is set to 0x10000 which is in the range of an unsigned
> > > > > short but not a short.  Isn't this problematic since most the ncurses
> > > > > APIs like wattr_set() expect a short?
> > > >
> > > > In the ncurses 5 ABI, the terminfo database file-format uses signed
> > > > shorts for everything, so values are clamped at 0x7FFF even if
> > > > logically they should be higher.
> > > >
> > > > In the ncurses 6 ABI, the terminfo database file-format has been
> > > > extended to allow larger numbers, so values generally do not need to be
> > > > clamped.
> > > >
> > > > For example, the new "xterm-direct" terminal description (xterm with
> > > > 24-bit colour) reports colors=0x1000000, although it still has
> > > > pairs=0x10000 because the actual number of possible pairs is a 49-bit
> > > > number, and ncurses *can't* allocate that many pairs just for memory-
> > > > allocation reasons.
> > > >
> > > > As for wattr_set(), the manpage says:
> > > >
> > > > > Each of the functions added by XSI Curses has a parameter opts,
> > > > > which X/Open Curses still  (after  more  than twenty  years)
> > > > > documents as reserved for future use, saying that it should be
> > > > > NULL.  This implementation uses that parameter in ABI 6 for the
> > > > > functions which have a color-pair parameter to support extended
> > > > > color pairs:
> > > > >
> > > > > •   For functions which modify the color, e.g., wattr_set, if opts
> > > > >     is set it is treated as a pointer to  int, and used to set the
> > > > >     color pair instead of the short pair parameter.
> > > >
> > > > > I could simply change my code to an unsigned short, but i'm not sure
> > > > > what that would do to ncurses.  Alternatively, I could simply
> > > > > redefine COLOR_PAIRS to 0x7FFF which is what Bionic Beaver uses.  As
> > > > > best I can tell, it looks like Fedora 29 made a poor decision.
> > > >
> > > > The current Debian Testing uses the ncurses 6 ABI, as does Ubuntu
> > > > Cosmic, so it's not just Fedora 29.
> > > >
> > > >
> > > > _______________________________________________
> > > > Bug-ncurses mailing list
> > > > address@hidden
> > > > https://lists.gnu.org/mailman/listinfo/bug-ncurses
> > > >
> > >
> > >
> > > --
> > > Bryan
> > > <><
> >
> > --
> > Thomas E. Dickey <address@hidden>
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
> >
>
>
> --
> Bryan
> <><

--
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

--

Bryan
<><