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
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's const), we could fault.
The text was updated successfully, but these errors were encountered:
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: