Re: COLOR_PAIRS on Fedora 29

[Bryan Christ]

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).  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?  

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
<><