Verified that both programs compile with
0gcc -I. -I../include -lsecp256k1 -c -W -Wextra -Wall -Werror -ansi -pedantic lax_der_privatekey_parsing.c
1gcc -I. -I../include -lsecp256k1 -c -W -Wextra -Wall -Werror -ansi -pedantic lax_der_parsing.c
Verified that both programs compile with
0gcc -I. -I../include -lsecp256k1 -c -W -Wextra -Wall -Werror -ansi -pedantic lax_der_privatekey_parsing.c
1gcc -I. -I../include -lsecp256k1 -c -W -Wextra -Wall -Werror -ansi -pedantic lax_der_parsing.c
I don’t see where the modules comment comes from? They’re now just ordinary C code, not weird header stuff. They’re still just code fragments, not libraries, not modules, not added to the build system, etc.
Oh you’re referring the linking into libsecp256k1? Yea, I don’t agree with that, but this patch doesn’t do that.
Would be good if it touched the build system enough to fix tests.c, however!
Turning it into full .c files with corresponding header files gives a pretty strong impression that this is code that is to be compiled and linked into your application as-is.
I really want to discourage that. You shouldn’t be compiling code from another project’s source tree. If that was the intention, we should just make it a compile time flag and expose it through the library.
This is an example code snippet you can copy-paste into your application or translate to another language as needed, making changes as needed too.
secp256k1_
prefixes from the functions to emphasize that they are not part of libsecp256k1 proper.
Verified that both programs compile with
gcc -I. -I../include -lsecp256k1 -c -W -Wextra -Wall -Werror -ansi -pedantic lax_der_privatekey_parsing.c
gcc -I. -I../include -lsecp256k1 -c -W -Wextra -Wall -Werror -ansi -pedantic lax_der_parsing.c
noinst_HEADERS
. Is this right?