-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compilation fails due to comparison of big integers #320
Comments
Is there a realistic case where we would have to convert an arbitrary high number to |
All field values used in length aspects need to be converted to
From the condition |
I think we should use a separate modular type solely for comparisons of field values. Length calculations should be in the |
I agree, but
That is what my original proposal was about. But this still does not answer my question. We are supporting 64-bit integer fields, so we also have to support comparisons of 64-bit integer fields. To repeat my original question:
|
I mixed that up with the length discussion. I think we should prohibit exponentiations. When we find a protocol that requires this we might have to change that but I think this is quite unlikely. |
As we have no type checking in our model, all field values are converted to a common integer type in the SPARK code before any calculation or comparison. Currently,
Bit_Length
is used for this purpose. While it makes sense to use this type for length calculations, it prevents the comparison of big integers. Here is an example:To cover all possible integer types, we would have to use a non-wrapping 64-bit modular type. The drawback of such a type is that current GNAT versions do not check overflows for exponentiations. Maybe we could prohibit the use of exponentiations in conditions as a workaround? @senier @jklmnn
The text was updated successfully, but these errors were encountered: