neo-project
AllowOverflow option to avoid checking int range
Changed the methodology. Skip range checks and throws with compilation option
Need a way to compile neo-devpack-dotnet\tests\Neo.Compiler.CSharp.TestContracts\Contract_BigInteger.cs with SimulateOverflow=true
Need a way to compile neo-devpack-dotnet\tests\Neo.Compiler.CSharp.TestContracts\Contract_BigInteger.cs with SimulateOverflow=true
Allowed CompilationOptions to be used in tests. TestGasConsume is set to false.
We should not save gas if the security is involved
No security problem is involved. This is just handling all int, long, short as BigInteger.
rather than allow overflow, i think biginteger only is better
Sometimes it's impossible to write BigInteger everywhere literally in codes. For example, shifting operations (>> and <<) in C# supports only int as the shifted count of bits. Also indexes of arrays have to be int. Then we have to write an explicit coversion (int) which wastes a range check.
And our current default settings (with or without my PR) are --checked=false (--allow-overflow=false). This allows silent overflows (from int.MaxValue to int.MinValue, without or without my PR). I think this is even more dangerous. Maybe it's better to have default as --checked=false --allow-overflow=true, or --checked=true --allow-overflow=false
we should detect
uncheckedkeyword
We are actually detecting it (with or without this PR). But by default everything is unchecked.
rather than allow overflow, i think biginteger only is better
Sometimes it's impossible to write BigInteger everywhere literally in codes. For example, shifting operations (>> and <<) in C# supports only int as the shifted count of bits. Also indexes of arrays have to be int. Then we have to write an explicit coversion (int) which wastes a range check.
excatly, just use what is allowed in biginteger.
This is an option that should be false by default, so after you @shargon reviewed, please dont merge it, i will update the test to remove the option and revert gas change.
I still don't know why we need this option, which is the use case?
where user can handle the integer range and no need to do automatic range check. currently, every numerous operation requires a range check, its expensive.
I still don't know why we need this option, which is the use case?
where user can handle the integer range and no need to do automatic range check. currently, every numerous operation requires a range check, its expensive.
expensive not because it's required for safety
gas examples to demonstrate gas saving. /or use biginteger as much as possible