Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

bytecode differs depending on if precise math is enabled

Description

After switching back to precise mode being off by default, the following tests started to fail

It seems different byte code is generated depending on the setting of precise mode

Failed test.functions.BitOr should correctly perform bitwise OR between two large String values Expected [18446744073709551615] but received [9223372036854778000] /test/functions/BitOr.cfc:58 Failed test.functions.BitXor Checking BitXOr() function with different large numbers Expected [18446744073709551614] but received [18446744073709552001] /test/functions/BitXor.cfc:50

 

both tests use application action="update" preciseMath=true;

https://github.com/lucee/Lucee/blob/6.2/test/functions/BitXor.cfc#L50

https://github.com/lucee/Lucee/blob/6.2/test/functions/BitOr.cfc#L58

but the bytecode differs depending on if the number is passed as a string or number

as number it’s LiteralValue.toNumber(paramPageContext, Long.MAX_VALUE)

paramPageContext.getFunction(paramPageContext.getFunction(paramPageContext.us(), keys[6], new Object[] { FunctionHandlerPool.invoke(paramPageContext, new Object[] { LiteralValue.toNumber(paramPageContext, "9223372036854775808"), LiteralValue.toNumber(paramPageContext, Long.MAX_VALUE) }"lucee.runtime.functions.math.BitOr") }), keys[7], new Object[] { LiteralValue.toNumber(paramPageContext, "18446744073709551615") }); application6 = (Application)((PageContextImpl)paramPageContext).use("lucee.runtime.tag.Application", "cfapplication", 4, "D:\\work\\lucee6\\test\\functions\\BitOr.cfc:66"); try { application6.setCgireadonly(true); application6.setTypechecking(true); application6.setAction("update"); application6.setPrecisemath(false); application6.doStartTag(); if (application6.doEndTag() == 5) throw Abort.newInstance(0); } finally { ((PageContextImpl)paramPageContext).reuse((Tag)application6); }

as string, it’s LiteralValue.toNumber(paramPageContext, "9223372036854778000")

paramPageContext.getFunction(paramPageContext.getFunction(paramPageContext.us(), keys[6], new Object[] { FunctionHandlerPool.invoke(paramPageContext, new Object[] { LiteralValue.toNumber(paramPageContext, "9223372036854778000"), LiteralValue.toNumber(paramPageContext, "9223372036854778000") }"lucee.runtime.functions.math.BitOr") }), keys[7], new Object[] { "18446744073709551615" }); application4 = (Application)((PageContextImpl)paramPageContext).use("lucee.runtime.tag.Application", "cfapplication", 4, "D:\\work\\lucee6\\test\\functions\\BitOr.cfc:59"); try { application4.setCgireadonly(true); application4.setTypechecking(true); application4.setAction("update"); application4.setPrecisemath(false); application4.doStartTag(); if (application4.doEndTag() == 5) throw Abort.newInstance(0); } finally { ((PageContextImpl)paramPageContext).reuse((Tag)application4); }

Environment

None

Activity

Show:

Pothys - MitrahSoft 17 December 2024 at 12:30
Edited

, I tested this ticket with Lucee version 6.2.0.218-SNAPSHOT. When I ran BitXor() and BitOr() with preciseMath set to false in admin mode, now return the expected results and work fine

Michael Offner 13 December 2024 at 10:30

Michael Offner 13 December 2024 at 10:28

solution is to exclude the “preciseMath“ setting from any compiler decision, so the result from the compiler works independent of that settings, of course still with the limitation that settings brings.

Michael Offner 13 December 2024 at 09:43

problem is that Lucee compiler detects, that you pass a literal string into a function takes a number as argument, so the compiler already optimizes and convert the string already to a Number at compilation time what causes an overflow.

Fixed

Details

Assignee

Reporter

Priority

Labels

Fix versions

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Sprint

Created 12 December 2024 at 13:38
Updated 15 March 2025 at 14:02
Resolved 17 December 2024 at 12:30

Flag notifications