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
We prefix all global names with secp256k1_ to avoid name collisions and ensure that the library can be header-only. If we believe in this, we should probably do the same for macros. (And even we don't believe in this, I tend to think that having a prefix everywhere is just more consistent.)
Perhaps it makes sense to separate internal macros and external "config" macros as suggested in #1121 (comment) by @sipa:
I think it may be useful to have a strict separation between "external" macros (provided in config.h, or through compiler -D flags) flags, and "internal" macros which guide the actual source code conditionals?
Also, we could reconsider the naming of the VERIFY macros as I suggested in #1381:
And while we're touching this anyway, we could consider renaming "check" to "assert", which is a more precise term. (In fact, if we redefine VERIFY_CHECK to be empty in production, we have almost reimplemented assert.h...)
The text was updated successfully, but these errors were encountered:
We prefix all global names with
secp256k1_
to avoid name collisions and ensure that the library can be header-only. If we believe in this, we should probably do the same for macros. (And even we don't believe in this, I tend to think that having a prefix everywhere is just more consistent.)Perhaps it makes sense to separate internal macros and external "config" macros as suggested in #1121 (comment) by @sipa:
Also, we could reconsider the naming of the
VERIFY
macros as I suggested in #1381:The text was updated successfully, but these errors were encountered: