tracker issue : CF-3831792

select a category, or use search below
(searches all categories and all time range)
Title:

Equality (eq) result is incorrect for some strings with numbers and commas or hyphens

| View in Tracker

Status/Resolution/Reason: To Track//NeedMoreInfo

Reporter/Name(from Bugbase): Dave Merrill / Dave Merrill (Dave Merrill)

Created: 09/25/2014

Components: Language

Versions: 9.0.1

Failure Type:

Found In Build/Fixed In Build: 9.0.1 /

Priority/Frequency: Major / All users will encounter

Locale/System: English / Windows 7

Vote Count: 1

Problem Description: Asking whether two strings are equal with the eq operator gives incorrect results in some cases, specifically some strings containing only numbers and commas or hyphens. Behavior of any given pair of strings is 100% consistent, but I don't see any logic to which ones give correct results and which ones don't.

Steps to Reproduce: Put the following code in a cfm file and run it:
<cfoutput><pre>
#"1821,9" eq "9,1821"#
#"12,91" eq "91,12"#+
#"1821,91" eq "91,1821"#

#"1821-9" eq "9-1821"#
#"12-91" eq "91-12"#
#"1821-91" eq "91-1821"#
<pre></cfoutput>

Actual Result:
YES
YES
NO

YES
YES
NO

Expected Result: None of those strings are actually the same, all tests should return NO.
NO
NO
NO

NO
NO
NO

Any Workarounds:
Use compare() instead of eq, or add a letter at the start or end of both values. But the bottom line is that this is very very wrong, and shouldn't have to be coded around.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3831792

Reason:	BugVerified

External Customer Info:
External Company:  
External Customer Name: dmerrill
External Customer Email:  
External Test Config: My Hardware and Environment details: Tested CF 9 and 11, behavior is the same, didn't test other versions. I'm on Windows 7 Pro SP1, behavior was also seen with CF 11 on Windows Server 2008 R2.

Attachments:

Comments:

It's interpreting the YES ones as dates: Sept 1821, Dec 1991, respectively. CF should NOT compare strings as dates: it should only do a date comparison if at least one operand is actually a date object, or if using dateCompare(). -- Adam
Comment by External U.
10830 | September 27, 2014 04:49:19 PM GMT
Interesting theory Adam. I hadn't come up with any rational explanation, guess that could be it. If so, this is case of loose typing gone seriously amuck. Hope something gets done about it, but I'm not completely sure what logic should be used to decide whether to do the date conversion. The approach you suggest certainly avoids this bizarre behavior, but it's possible there's code out that relies on comparing dates in different formats, like this is trying to do. In my case, they're not dates at all, they're lists of IDs for records whose order a method is trying to set. The code checks if they're already in the requested order before doing anything, so those false positives caused it to be a no-op when the data tickled this bug.
Comment by External U.
10831 | September 27, 2014 05:14:07 PM GMT
+1 ......................
Vote by External U.
10832 | November 24, 2014 04:59:45 AM GMT