-
Notifications
You must be signed in to change notification settings - Fork 8
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
Examine const-correctness #4
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, most of the by-reference parameters in our functions, especially internal ones, are not
const
. Even when logically they definitely should be.This is a bit of a sticky wicket, because AMCL's API doesn't use
const
, and many of those functions do have side-effects on their parameters, sometimes subtly so.Further, taking our parameters as
const
then casting the const away can be dangerous, even when the source code appears to not modify the parameter, because the compiler may get too smart. For example, if the machine code from AMCL ends up doing something cute where the memory gets updated then changed back (allowed because the AMCL code took it as non-const
), but that memory is actually ROM (because our code, which defined it, said it'sconst
), we could fault.The text was updated successfully, but these errors were encountered: