Skip to content
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

Prefix all macros with SECP256K1_ #1449

Open
real-or-random opened this issue Dec 1, 2023 · 0 comments
Open

Prefix all macros with SECP256K1_ #1449

real-or-random opened this issue Dec 1, 2023 · 0 comments
Labels
meta/development processes, conventions, developer documentation, etc. refactor/smell

Comments

@real-or-random
Copy link
Contributor

real-or-random commented Dec 1, 2023

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...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta/development processes, conventions, developer documentation, etc. refactor/smell
Projects
None yet
Development

No branches or pull requests

1 participant