Fun bug I found. On this page (click to view it):
…user TonyMonast gives a code sample involving CFLOOP. Having just downloaded Lucee 6, I was eager to run code snippets like these that are problematical back when Lucee used “double” for calculations but should work correctly now that Lucee 6 uses “BigDecimal” instead. So I ran this code, stripping out the round() functions, to see if the results were now correct thanks to BigDecimal being used behind the scenes.
Thing is, it still didn’t work, and gave some wacky .0000000001 and .9999999999 type stuff.
Curious, I messed around with it. I figured loop index variable incrementing via CFLOOP with the STEP attribute may not have been converted to “BigDecimal” and may still be using “double”.
Sure enough, that was correct! Once I rewrote the CFLOOP to be a simple integer 1-10000 from/to loop using an integer index variable that never gets looked at, and created a new variable that I increment manually by 0.01 on each iteration in a cfset with the + operator, the output was perfect.
So, the devs may want to extend the “BigDecimal” treatment to additions done internally in non-integer CFLOOP / STEP situations.
If this isn’t desirable due to performance considerations (loops should be speedy) then don’t change it to BigDecimal, but make sure to let everyone know, so if they’re going to use the STEP attribute they should stick to only integers, otherwise they should figure out some other alternate way to code the loop that avoids non-integer STEP values (like I did, above).
Hope that helps!
OS: Linux
Java Version: 11.0.11
Lucee Version: 6.1.0.243 (Express version)
Tomcat Version: 8 (why does it come with 8 anyway? Lucee 5 Express came with 9!)