Re: [PATCHv2] gdb/tui: use init_extended_color where possible

[Tom Tromey <tom@tromey.com>]

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:

Andrew> The motivation for using init_extended_color is slightly less than
Andrew> init_extended_pair.  Assuming the terminal supports it the standard
Andrew> init_color API supports up to SHRT_MAX (32767) different colors,
Andrew> switching to init_extended_color removes the SHRT_MAX limit on color
Andrew> indices, allowing us to support the full range of COLORS.

First, I think the patch is fine.
Approved-By: Tom Tromey <tom@tromey.com>

However I have a question

Andrew>  	  /* We store RGB as 0..255, but curses wants 0..1000.  */
Andrew> -	  if (init_color (next, rgb[0] * 1000 / 255, rgb[1] * 1000 / 255,
Andrew> -			  rgb[2] * 1000 / 255) == ERR)
Andrew> +	  short r = rgb[0] * 1000 / 255;
Andrew> +	  short g = rgb[1] * 1000 / 255;
Andrew> +	  short b = rgb[2] * 1000 / 255;
Andrew> +
Andrew> +	  /* If init_extended_pair is not available then we fallback to
Andrew> +	     using init_pair.  However, init_pair can only handle 'short'
Andrew> +	     color indices so there is no point using init_extended_color
Andrew> +	     to allow for the generation of longer 'int' color indices.  */
Andrew> +#if defined HAVE_INIT_EXTENDED_COLOR && defined HAVE_INIT_EXTENDED_PAIR
Andrew> +	  if (init_extended_color (next, r, g, b) == ERR)
Andrew>  	    return false;
Andrew> +#else
Andrew> +	  /* NEXT is an int, but is passed as a short.  If COLORS is
Andrew> +	     more than SHRT_MAX then NEXT will be truncated and end up
Andrew> +	     redefining a color entry that we don't expect.  */
Andrew> +	  if (next > SHRT_MAX
Andrew> +	      || init_color (next, r, g, b) == ERR)
Andrew> +	    return false;
Andrew> +#endif

IIUC init_extended_color allows a bigger range for 'next' but also for
the RGB components.  However despite the text above, I think we don't
actually use the bigger RGB range.  And, perhaps we don't really care
to, I don't know.

Tom