From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 64e25cd: More robust NS hex colour string parsing Date: Sat, 13 Jun 2020 20:09:02 +0300 Message-ID: <83v9ju3nbl.fsf@gnu.org> References: <20200608120746.30163.87810@vcs0.savannah.gnu.org> <20200608120747.80E8E20A2E@vcs0.savannah.gnu.org> <83r1uk429y.fsf@gnu.org> <3C92A091-F389-4179-B2F0-B3AA5ABD6CCE@acm.org> <83pna43xrl.fsf@gnu.org> <9259B4A6-F3CC-4243-9F08-2882993C9B2C@acm.org> <83a71741mr.fsf@gnu.org> <83y2or2c0o.fsf@gnu.org> <82DE05DD-0F2A-4722-AB75-D9D95F58BAF4@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="66350"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@gmail.com, emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 13 19:10:00 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jk9fM-000H4c-Et for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 19:10:00 +0200 Original-Received: from localhost ([::1]:49774 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jk9fL-00040l-I9 for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Jun 2020 13:09:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53208) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jk9ea-0003DU-CX for emacs-devel@gnu.org; Sat, 13 Jun 2020 13:09:12 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60501) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jk9eZ-0006Aw-UY; Sat, 13 Jun 2020 13:09:11 -0400 Original-Received: from [176.228.60.248] (port=3779 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jk9eZ-0007Pa-DF; Sat, 13 Jun 2020 13:09:11 -0400 In-Reply-To: <82DE05DD-0F2A-4722-AB75-D9D95F58BAF4@acm.org> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Sat, 13 Jun 2020 18:44:04 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252190 Archived-At: > From: Mattias Engdegård > Date: Sat, 13 Jun 2020 18:44:04 +0200 > Cc: pipcet@gmail.com, emacs-devel@gnu.org > > 13 juni 2020 kl. 17.58 skrev Eli Zaretskii : > > >> Try (color-values "#123"). The correct result is (#x1111 #x2222 #x3333). > > > > Why is that the correct value? I get (#x1010 #x2020 #x3030); why is > > that wrong? > > It violates the HTML/CSS convention which was agreed upon in bug#36304 and followed by the other backends. Single-digit hex numbers are scaled by 65535/15, two-digit numbers by 65535/255, and three-digit numbers by 65535/4095. But the code you want to supplant explicitly does something different: value = strtoul (color, &end, 16); color[size] = t; if (errno == ERANGE || end - color != size) break; switch (size) { case 1: value = value * 0x10; break; case 2: break; case 3: value /= 0x10; break; case 4: value /= 0x100; break; } That multiplication by 0x10 cannot be a typo, it's a deliberate interpretation of #f as #f0, not as #0f or #ff. Of course, single-digit hex RGB specs are rarely if ever used these days, AFAIK, so maybe this isn't a problem in practice. But still, I wonder what could we lose here or break. > > Just follow the code, it should be very clear: those two branches > > always return a list of values. No example should be needed. > > An example could help resolve misunderstanding, and if we go back-and-forth on what you think is a simple matter it's a clear sign that one is definitely needed. > > > No, that's not true, as should be obvious from examining the code. > > Previously, any "#..." string whose length was 4 or longer would > > return a list of values, even if it wasn't well-formed; now some of > > them will return nil. > > (tty-color-values "#xyz") returned nil (and still does), contradicting your claim. How about (tty-color-values "#12345")? does it contradict yours? > I meant that the manner of rejection remains unchanged, not the set of rejected arguments, which is a consequence of improved error-checking, very much by design. > Not only was it previously lacking, its coverage varied wildly between backends. That means that hardly any code could have abused the lax checking while still working on multiple platforms. Of course, the unpredictable behaviour on malformed input made this a very dubious endeavour in the first place. You are changing the behavior, so get ready to hear bug reports, is all I'm saying. > > color-values-from-rgb-spec? > > Thank you, but that would preclude addition of non-RGB formats in the future, such as HSV or XIE XYZ. Nothing in the interface forces the specification to be RGB. In fact, Xlib accepts several non-RGB formats. Then color-values-from-color-spec, I guess.