bug#41544: 26.3; Possible incorrect results from color-distance

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Thu, 4 Jun 2020 17:29:06 +0200
> Cc: tom@tromey.com, simon@polaris64.net, 41544@debbugs.gnu.org
> 
> 1. color-name-to-rgb calls (color-values "#ffffffffffff") as a means to get 
> the range of the colour values.

There's some history to that: see bug#25890.

> 2. With TERM=xterm-color, there are 8 colours. These are assumed to be the 8 
> first of xterm-standard-colors (xterm.el).
> 3. The colour closest to "#ffffffffffff" is "white", with the values (229 229 
> 229), or translated to 16 bit/channel, (#e5e5 #e5e5 #e5e5) which color-values 
> returns.
> 4. "blue" has the values (0 0 238), or (0 0 #xeeee).
> 5. Thus color-name-to-rgb returns #xeeee/#xe5e5 for the blue channel, or 
> 1.039, which is a clear bug.

What bad results does this issue cause in practice?

(Btw, in a GUI session I see (0.0 0.0 1.0), so no problem there.)

> The main problem is trusting "#ffffffffffff" to match a colour with the 
> maximum range.

Why is that a problem, given the color representation we use in Emacs?

> It could be argued that xterm.el shouldn't use subdued colours when only 8 
> are present; I didn't go far back in XTerm history to find out. Modern XTerm 
> has default colours 0-7 that correspond to the assumptions of Emacs.
> 
> Since we already document that the colour channel maximum is either 65535 or 
> 65280 depending on platform, taking the very roundabout way of trying to 
> match a sufficiently white colour and using its components is demonstrably 
> unsafe and error-prone, as well as unnecessarily slow. Hence 
> color-component-max in the patch.

Sorry, you lost me here.  I don't understand what you are saying here
and what does that have to do with the problem being discussed.

> This also fixes a different problem: if the display hasn't been initialised 
> fully, such as when running in batch mode, then (color-values 
> "#ffffffffffff") returns nil, and as we shall see later, it may be useful to 
> be able to call color-name-to-rgb at this stage without crashing.

This command:

  emacs -batch --eval "(message \"%s\" (color-name-to-rgb \"white\"))"

yields "(1.0 1.0 1.0)" on my system with today's master branch, and
this command:

  emacs -batch --eval "(message \"%s\" (color-values \"#ffffffffffff\"))"

yields "(65535 65535 65535)", so I don't think I understand what
problem you are concerned with here, and how can this cause a crash.
Please elaborate.