(cherry-pick): Fixed bug [f0188aca9e] (color names parsing on Windows), by Simon Bachmann

2 files changed, 33 insertions, 1 deletions

diff --git a/tests/color.test b/tests/color.test
index a7ed1f8..aa20099 100644
--- a/tests/color.test
+++ b/tests/color.test
@@ -90,7 +90,17 @@ proc colorsFree {w {red 31} {green 245} {blue 192}} {
 	    && ([lindex $vals 2]/256 == $blue)
 }
 
-if {[testConstraint psuedocolor8]} {
+# -- WARNING (SB, 6.4.2017) --
+#
+# The if block below looks _very_ outdated. It didn't get any
+# substantial changes as far back as the fossil history goes. It might
+# be from a time, when 256 color was the best you could get! :-o.
+#
+# The problem is, on machines with a fancy 24 truecolor display, the
+# 'colorsFree' constraint doesn't get set, turning off pretty much every test
+# in this file.
+
+if {[testConstraint pseudocolor8]} {
     toplevel .t -visual {pseudocolor 8} -colormap new
     wm geom .t +0+0
     mkColors .t.c 40 6 0 0 0 0 6 0 0 0 40
@@ -185,6 +195,18 @@ test color-2.6 {Tk_GetColor procedure} {colorsFree nonPortable} {
 test color-2.7 {Tk_GetColor procedure} colorsFree {
     winfo rgb .t #ff0000
 } {65535 0 0}
+test color-2.8 {Tk_GetColor, invalid char after 3 valid hex digits} -body {
+    winfo rgb . #abcg
+} -returnCodes error -result {invalid color name "#abcg"}
+test color-2.9 {Tk_GetColor, invalid char after 6 vaild hex digits} -body {
+    winfo rgb . #aabbccz
+} -returnCodes error -result {invalid color name "#aabbccz"}
+test color-2.10 {Tk_GetColor, 3 hex digits, last one invalid} -body {
+    winfo rgb . #abz
+} -returnCodes error -result {invalid color name "#abz"}
+test color-2.11 {Tk_GetColor, 6 hex digits, last one invalid} -body {
+    winfo rgb . #12345g
+} -returnCodes error -result {invalid color name "#12345g"}
 
 test color-3.1 {Tk_FreeColor procedure, reference counting} colorsFree {
     eval destroy [winfo child .t]
diff --git a/xlib/xcolors.c b/xlib/xcolors.c
index 66591c7..7b7223c 100644
--- a/xlib/xcolors.c
+++ b/xlib/xcolors.c
@@ -345,6 +345,16 @@ XParseColor(
 	char *p;
 	Tcl_WideInt value = parseHex64bit(++spec, &p);
 
+	/*
+	 * If *p does not point to the end of the string, there were invalid
+	 * digits in the spec. Ergo, it is not a vailid color string.
+	 * (Bug f0188aca9e)
+	 */
+	
+	if (*p != '\0') {
+	    return 0;
+	}
+	
 	switch ((int)(p-spec)) {
 	case 3:
 	    colorPtr->red = US(((value >> 8) & 0xf) * 0x1111);