Floats/Doubles could lead to non-deterministic results via different platforms for SC's #2
Description
See Ref:
https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/
"What is not guaranteed
Unfortunately there are a significant number of things that are not guaranteed. Many of these things can be controlled so they should not be problems, but others can be tricky or impossible. Which is why the answer is both “yes” and “no”.
Floating-point settings (runtime)
There are a number of settings that control how floating-point math will be done. The IEEE standard mandates several different rounding modes and these are usually expressed as per-thread settings. If you’re not writing an interval arithmetic library then you’ll probably keep the rounding mode set to round-to-nearest-even. But if you – or some rogue code in your process – changes the rounding mode then all of your results will be subtly wrong. It rarely happens but because the rounding mode is typically a per-thread setting it can be amusing to change it and see what breaks. Troll your coworkers! Amuse your friends!
If you are using the x87 floating-point unit (and on 32-bit x86 code you can’t completely avoid it because the calling conventions specify that an x87 register is used to return floating-point results) then if somebody changes the per-thread precision settings your results may be rounded to a different precision than expected."
Possible Issues from this:
Could lead to a variety of issues and exploits with account states. If 2 different group of nodes 2 different floating point settings then the 2 groups of nodes will both have a different possible return values and logic executions for the same smart contract.
Solution:
When floats/Doubles are used in Java Smart contracts make sure the nodes check for the keyword 'strictfp' to ensure the same result on all machine/hardware types.
"Programmers can use the modifier strictfp to ensure that calculations are performed as in the earlier versions; that is, only with IEEE single and double precision types used. Using strictfp guarantees that results of floating-point calculations are identical on all platforms. "
https://en.wikipedia.org/wiki/Strictfp
https://www.codejava.net/java-core/the-java-language/java-keyword-strictfp
This only applies to older machines with different floating points.
Yes strictfp is useless on modern CPUs, but if we do not plan to support older CPU's then they shouldn't be allowed to be a node.