In C programming, I have a set of information, and I have to ways of providing it to user:
- construct a data structure and provide it as an object.
- write a function to read them out and return them.
I used 2 for part of my project - some of my users expect to have those values available at compile-time, so function-like macros are needed, and the user code can work with both function-like macros and actual functions.
Here's my project, it's a cryptography library. And here's some background information.
Method 2 is used for obtaining working context size, key/block/output size for hash functions, AEAD ciphers, etc. and it work well for most symmetric-key algorithms. 2 is also used for asymmetric-key algorithms including key encapsulation mechnism and digital signature schemes.
Where compile-time and link/run-time deviates is when they're instantiated.
When an algorithm is instantiated at compile-time, a function-like macro is defined taking its parent algorithm, and specifying a parameter - take HMAC for example, HMAC is the parent algorithm, and a hash algorithm is the parameter.
When an algorithm is instantiated at link/run-time, a pointer to an object of type
CryptoParam_t is specified as parameter.
But now, some of the information is known to be only available at run-time (or at least link-time) - asymmetric-key algorithm key-generation functions can only take
CryptoParam_t objects is among the reasons. So is it better to just use 1? Is it an anti-pattern to use 2 now?