Has this bug been noted already Not sure what to search for cfml #adobe

Has this bug been noted already? Not sure what to ...

brandner

08/26/2022, 10:53 PM

Has this bug been noted already? Not sure what to search for to confirm - https://tracker.adobe.com/#/view/CF-4214883 - comparing two strings if the strings have a dot at the end seems to give unexpected results. CF2021 only.

Daniel Mejia

08/26/2022, 10:56 PM

Wow. So the work around for this is to remove the period at the end then compare? There isn’t any good or consistent updates on those cases. But that doesn’t mean it wasn’t fixed. if you use commandbox you can spin up a server with the latest update and test it.

brandner

08/26/2022, 10:57 PM

Ya, workaround is just to do a better compare. For example, ListFirst() for IP addresses, or whatever. Still a brutal bug. I think I have the latest.

Daniel Mejia

08/26/2022, 10:57 PM

Then it hasn’t been fixed.

brandner

08/26/2022, 10:58 PM

I was more worried that I was reporting a bug that someone else noted... couldn't find anything though.

websolete

08/26/2022, 11:28 PM

it's doing some kind of goofy implicit cast to numeric. note the last example here works under 2021 while the other two do not. https://trycf.com/gist/c928ca54215f5934ba82fc3d38080076/acf2021?theme=monokai would still call it a bug

websolete

08/26/2022, 11:30 PM

the same code in lucee5 returns the exact opposite

Adam Cameron

08/27/2022, 9:45 AM

This slight variation (clearer output, one extra test) shows what's going on more clearly, perhaps: https://trycf.com/gist/3df40b9b9c78eecee4bb28c620121543/acf2021?theme=monokai

https://i2.paste.pics/e13262dc3092eec8fe49625f7b4d38a7.png▾

https://i2.paste.pics/611adc9f40476237329426995c8914f7.png▾

Adam Cameron

08/27/2022, 9:52 AM

CF considers

"123."

to be numeric, so seems to be coercing the

testSubString

value into a numeric, so

and but it does not do the same to the literal

"123."

so... what... ends up coercing the numeric back into a string (

"123"

now) before comparing with

"123."

, which are clearly not the same. With

===

it leaves

testSubString

as-is, so both strings are

"123."

, and match. --- Lucee doesn't consider

"123."

to be numeric, so none of the back/forth coercion takes place for the

EQ

and

==

operations. And it just messes up the

===

one. There's no way that should not be

true

Adam Cameron

08/27/2022, 10:12 AM

Ugh. Simplified a bit more (no need to do both

eq

and `==`: they are the same), but added in another numeracy test, and checked a difference in how literals and variables are handled: https://trycf.com/gist/c8e2d796c583de66c04cddd2472299a3/lucee5?theme=monokai

Copy code

testString = "123.456.789.000";
testSubString = Left(testString,4);

compareTo = "123."

writeDump([
    "testString" = testString,
    "testSubString" = testSubString,
    "isNumeric(testSubString)" = isNumeric(testSubString),
    "testSubString * 1" = testSubString * 1,
    'testSubString EQ "123."' = testSubString EQ "123.",
    'testSubString == "123."' = testSubString == "123.",
    'testSubString === "123."' = testSubString === "123.",
    "compareTo" = compareTo,
    "testSubString EQ compareTo" = testSubString EQ compareTo,
    "testSubString == compareTo" = testSubString == compareTo,
    "testSubString === compareTo" = testSubString === compareTo
])

https://i2.paste.pics/81f6ff10b08c388060dab88a57a4937e.png▾

https://i2.paste.pics/d6f06274b15da46d926f130c46cb8f2f.png▾

Lucee claims

"123."

is not numeric, but then happily allows it to be used as one. It's gotta be one way or the other. Bug. CF handles string literals differently to string variables (see the

==

test on both: different results). Bug. And Lucee's bug with

===

. I do so love CFML.

Adam Cameron

08/27/2022, 10:43 AM

Needless to say: PHP (https://onlinephp.io/c/fae8a) and Ruby (https://replit.com/@dacameron/ClearThistleArrays#main.rb) get all of it right for equivalent code.

Dave Merrill

08/27/2022, 11:59 AM

Ugh generally. Makes you think there might not be unit tests for the core language don't it.

Adam Cameron

08/27/2022, 2:32 PM

It's been made clear to me that the CF Team are very "narrow focused" in their test cases. They only seem to write those sort of tests that "demonstrate the code does what I mean for it to do", without giving much thought to much other than the most obvious happy path, and def not testing edge cases. It's also pretty clear they backfill the tests after the code is written, rather than doing the tests first. By doing this they kinda test their implementation, rather than the requirement. Lucee seems about the same.

Adam Cameron

08/27/2022, 2:39 PM

Was just about to write a blog article on this, only to realise I already have: https://blog.adamcameron.me/2022/05/cfml-with-lucee-true-isnt-necessarily.html Although the

isNumeric

behaviour on Lucee is new to me, I think.

Adam Cameron

08/27/2022, 2:39 PM

I recommend ppl go vote for this: https://luceeserver.atlassian.net/browse/LDEV-1282

seancorfield

08/27/2022, 3:49 PM

And the bottom line probably should be: use

compare()

compareNoCase()

for string comparisons in CFML?

mtbrown

08/27/2022, 10:29 PM

Agreed. I learned early on using CFML that using

EQ

and

NEQ

for string comparisons can be fraught. I always use

compare

compareNoCase

brandner

08/29/2022, 2:48 PM

Good tip guys, thx

Open in Slack

Previous Next