Re: master 64e25cd: More robust NS hex colour string parsing

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sat, 13 Jun 2020 12:17:09 +0200
> Cc: pipcet@gmail.com, emacs-devel@gnu.org
> 
> 12 juni 2020 kl. 21.11 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > The error checking aside, are
> > the return values of the original code the same as of the proposed
> > unified code?
> 
> Returned values for well-formed input are identical

That's good to know, thanks.

> except the low bits in some cases on Windows (try "#123")

I don't think I understand what I should try; please elaborate.

> Malformed arguments are now consistently rejected.

How exactly are they rejected?  I see the return value of
parse_color_spec, but what happens in its callers, and what happens on
the Lisp levels when those callers are called?

> > At least tty-color-standard-values seems to never return nil for an
> > RGB spec, but now it will, right?  Can its callers cope with such a
> > return value?
> 
> Not sure what you mean here. Mind giving a concrete example?

The first two branches of the 'cond' would always return a list before
your changes, but after your changes they could return nil if
color-values-from-numeric-string (not the best name, btw) returns nil
and the input is of one of the two forms parsed by those two branches.