You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am trying to define a function which takes a 6-bit integer u6 and further does stuff (not relevant) with it. I noticed that even if I define such a function, e.g. foo(var: u6), that input which is clearly not 6-bits in size is allowed foo(9999999999999999999).
This lead me to adding range checking on the input, however I believe that in the past attempting to invoke foo this way would result in an error. Anyway, range checking:
fnfoo(alpha:BitboardIndex){let beta:u6 = alpha asu6;println(f"Alpha(untouched):{alpha} / Beta:{beta}");// This always INCORRECTLY passes because invalid input for `alpha` of type// larger than 6-bit is range constrained down to the modulo of the input// value and the input-parameters-type's maximum value.// So an input of 0x93 here will result in `alpha` of 0x13 (0x93 % 0x40 = 0x13).assert(0 <= beta & beta <= 63);}
The above function foo's assertion will always pass. Even if called with values above 6-bit.
While not shown in the println output for foo if I define a function bar:
You can see (when run) that beta becomes equal to the last nibble of the constrained value given to bar and since 2^4 will always be within closed range 0 - 63 the assertion always passes.
For input values which are already valid println shows the values correctly.
I feel like this wasn't the case in the past. Calling foo or bar with an incorrect value (as known at compile-time since these are static) should be an error, no? If not then range constraints feel useless within code however apparently will result in a proof failing verification. Although given the nature of the range constraining here I imagine it is possible to be VERY unlucky and somehow result in a valid value still which passes proof verification?
Expected Behavior
Obvious (statically inferable) invalid input to functions should result in a compiler error the same as mismatched types do.
If not, range checking should not produce unexpected results and such casting should result in invalid values or consistent values (e.g. always 0 and not the last nibble of the input).
Bug
Nargo version:
nargo 0.16.0 (git version hash: c4faf3a0a40eea1ee02e11dfe08b48c6b4438bbf, is dirty: false)
use dep::std::println;typeBitboardIndex = u6;fnfoo(alpha:BitboardIndex){let beta:u6 = alpha asu6;println(f"Alpha(untouched):{alpha} / Beta:{beta}");// This always INCORRECTLY passes because invalid input for `alpha` of type// larger than 6-bit is range constrained down to the last hex-digit of// the invalid input.assert(0 <= beta & beta <= 63);}fnbar(alpha:Field){let beta:u6 = alpha asu6;println(f"Alpha(untouched):{alpha} / Beta:{beta}");assert(0 <= beta & beta <= 63);}#[test]fntest(){println(f"");// Fix missing newline after Nargo test-name output.println(f"Foo tests ----------------------------------------------------"); foo( 0x39, // Within 6-bits (decimal 63). ); foo( 0x40 // NOT within 6-bits (decimal 64). ); // Obviously both are much larger than 6-bits. foo(0x85); foo(0x8c3defb1edb984fe2ac71c71c7); println(f"Bar tests ----------------------------------------------------");bar(0x39,// Within 6-bits (decimal 63).);bar(0x40// NOT within 6-bits (decimal 64).);// Obviously both are much larger than 6-bits.bar(0x85);bar(0x8c3defb1edb984fe2ac71c71c7);}
To Reproduce
Use nargo version as described above.
Paste source code as described above.
Run command as described above.
Installation Method
Compiled from source
Nargo Version
nargo 0.16.0 (git version hash: c4faf3a, is dirty: false)
Additional Context
No response
Would you like to submit a PR for this Issue?
Maybe
Support Needs
No response
The text was updated successfully, but these errors were encountered:
Aim
I am trying to define a function which takes a 6-bit integer
u6
and further does stuff (not relevant) with it. I noticed that even if I define such a function, e.g.foo(var: u6)
, that input which is clearly not 6-bits in size is allowedfoo(9999999999999999999)
.This lead me to adding range checking on the input, however I believe that in the past attempting to invoke
foo
this way would result in an error. Anyway, range checking:The above function
foo
's assertion will always pass. Even if called with values above 6-bit.While not shown in the
println
output forfoo
if I define a functionbar
:You can see (when run) that
beta
becomes equal to the last nibble of the constrained value given tobar
and since 2^4 will always be within closed range 0 - 63 the assertion always passes.For input values which are already valid
println
shows the values correctly.I feel like this wasn't the case in the past. Calling
foo
orbar
with an incorrect value (as known at compile-time since these are static) should be an error, no? If not then range constraints feel useless within code however apparently will result in a proof failing verification. Although given the nature of the range constraining here I imagine it is possible to be VERY unlucky and somehow result in a valid value still which passes proof verification?Expected Behavior
Bug
Nargo version:
Command:
Sources:
Nargo.toml
To Reproduce
nargo
version as described above.Installation Method
Compiled from source
Nargo Version
nargo 0.16.0 (git version hash: c4faf3a, is dirty: false)
Additional Context
No response
Would you like to submit a PR for this Issue?
Maybe
Support Needs
No response
The text was updated successfully, but these errors were encountered: