Possible TCL Bug with String Comparison in 5.8.4?

[Travis Farrar]

We’re in the process of upgrading to 5.8.4 from 5.5Rev1 and I ran across something while testing an xlate. We have some TCL code to look for a “+” or “-” character for a charge interface we have. If we see a “-” in FT1-6 we multiply FT1-10 by -1. Works fine in 5.5Rev1 but in 5.8.4 it fails due to incorrect evaluation when comparing the “+” and “-” characters when using the “==” operator.  I thought it might be something with the testing tool but when I go to the shell and enter the TCL expression there I get the same result. We do have a workaround because it works using other operators for string comparison. I thought I might post it though to see if anyone else is experiencing this. Here is the output so you may see what I am talking about:

Code:

hcitcl>if {”+” == “-“} {echo “true”} else {echo “false”}
true
hcitcl>if {”+” eq “-“} {echo “true”} else {echo “false”}
false
hcitcl>string compare “+” “-”
-1
hcitcl>if {[cequal “+” “-“]} {echo “true”} else {echo “false”}
false

I noticed there was a bug supposedly fixed in 5.8.4 related to the format command and incorrectly parsing negative numbers. However these are being treated as strings so I wouldn’t think the two are related.

Anyone else having issues using “==” operator for string comparison?

Topic

[Robert Milfajt]

From the TCL Wiki:

Quote:

==  Equality and inequality. Note that these operations work on strings as

!=   well as numbers, but you are probably better off testing the result of

      string equal instead as that is more predictable in the case of a string

      that looks like a number. For example, string equal considers “6”

      and “06” to be different strings, but expr’s == considers them to be

      equivalent numbers.  

eq   (2004-07-08 added): From Tcl 8.4 on. The same as before, but

ne   arguments only strings. Will find “6” and “06” (as well as 1 and 1.0)

       to be different.  

I’m guessing that + and – evaluate to +0 and -0 using ==, but that’s only an educated guess!

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Chris Williams]

Best practices:

Quote:

String values may be used as  operands  of  the  comparison  operators, although the expression evaluator tries to do comparisons as integer or floating-point when it can, except in the case of the eq and ne  operators.  If one of the operands of a comparison is a string and the other has a numeric value, the numeric operand is converted back to a  string using  the C sprintf format specifier %d for integers and %g for floating-point values.  For example, the commands

      expr {“0x03” > “2”}

      expr {“0y” < "0x12"}

both return 1.  The first comparison is done using integer  comparison, and the second is done using string comparison after the second operand is converted to the string 18.  Because of Tcl’s tendency to treat values as numbers whenever possible, it isn’t generally a good idea to use operators like == when you really want string comparison and the values of  the operands could be arbitrary;  it’s better in these cases to use the eq or ne operators, or the string command instead.

[David Barr]

Yeah, my recommendation is to modify your code that is using “==” for string comparison to use “eq” instead.

It is interesting (and I’m seeing this, too) that the behavior is different between Cloverleaf 5.7 and 5.8.4 even though the TCL patch level is the same.

[Travis Farrar]

Thanks for all the responses. It looks like it is better to use eq for strings which I was unaware of until now and I have modified the code to do that. It does work now as expected.

I guess I was confused because I thought the == could pretty much be used for anything including strings. We have a book “Tcl and the Tk Toolkit” written by John K. Ousterhout, the guy who actually created Tcl and Tk and in this book there is a table which says the operand types for the == are int, real, string. So I thought it simply would have treated the + and – as strings.

However, since eq appears to be best practice I’ll try to use that from now on. Thanks again guys!

[Robert Milfajt]

In your case, you know that the data is a string, so I would recommend using string equal, i.e.,

Code:

if [string equal $x $y] {echo “true”} else {echo “false”}

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Levy Lazarre]

I agree with Robert.

Both the “==” and “eq” operators will try to first treat the operands as numbers. If one or both operands cannot be parsed as numbers, then they will perform a string comparison.

If you know from the start that you are comparing two strings, it is better to use the “string equal” command which saves you a step and always gives predictable results.

Strangely, I tried the first example at a Tclsh 8.4 prompt, and I am getting the expected result (false). So it appears that the issue we are seeing is a problem with hcitcl, not Tcl itself:

Code:

% if {”+” == “-“} {echo “true”} else {echo “false”}
false
%

[Travis Farrar]

I’ve been going through our Tcl procs and changing any string comparisons that use the == operator and instead using the alternative suggestions.  Interesting that this works as expected from a Tcl shell prompt. I guess it’s just a bug with hcitcl.

[Author]

Replies