Add functions exposing constants for all operation/primitive pairs

[stouset]

Wrappers for other languages can't access constants defined by C
preprocessor macros, so they must be exposed as functions. This was
already done for the "default" implementation of each operation, but
this commit adds functions for (almost) all of the underlying
primitives.

A few are currently excluded due to problems with the automated script
used to generated this commit. They are:

• crypto_onetimeauth_poly1305
• crypto_generichash_blake2b
• crypto_verify16
• crypto_verify32

[stouset]

In case you're morbidly curious, this was done with:

find src/libsodium/include/sodium -name "crypto_*_*.h" | cut -d\/ -f5 | sed -e 's/\.h//' | tr "_" " " | cut -d\  -f 2,3  | while read OPER PRIM; do IMPL=$(find src/libsodium/crypto_${OPER}/${PRIM} -type d -mindepth 1 -maxdepth 1 | head -1 | cut -d\/ -f5); (echo \#include \"crypto_${OPER}_${PRIM}.h\" && cat src/libsodium/crypto_${OPER}/${PRIM}/${IMPL}/api.h | egrep "#define\s+crypto_[[:alpha:]]+_[A-Z]+" | grep -v IMPLEMENTATION | grep -v PRIMITIVE | sed -E "s/#define crypto_${OPER}_([[:alpha:]]+.*)/\1 size_t/g" | tr " " "\t" | sed -E 's/(\"[[:alnum:]]+\"[[:space:]]+)size_t/\1const char */' | awk -F\t "{ print \"\n\" \$3 \"\ncrypto_${OPER}_${PRIM}_\" tolower(\$1) \"(void) {\n    return \" \$2 \";\n}\" }") > src/libsodium/crypto_${OPER}/${PRIM}/${OPER}_${PRIM}.c; sed -e "/crypto_${OPER}\/${PRIM}\/${IMPL}\/api.h/i \\
\ \ \ \ \ \ \ crypto_${OPER}/${PRIM}/${OPER}_${PRIM}.c \\\\
" -i '' src/libsodium/Makefile.am; sed -e '/#include "export.h"/i \
#include <stddef.h>' -i '' src/libsodium/include/sodium/crypto_${OPER}_${PRIM}.h; DEFS=$(cat src/libsodium/crypto_${OPER}/${PRIM}/${IMPL}/api.h | egrep "#define\s+crypto_[[:alpha:]]+_[A-Z]+" | grep -v IMPLEMENTATION | grep -v PRIMITIVE | sed -E "s/#define crypto_${OPER}_([[:alpha:]]+.*)/\1 size_t/g" | tr " " "\t" | sed -E 's/(\"[[:alnum:]]+\"[[:space:]]+)size_t/\1const char */' | awk -F\t "{ print \"SODIUM_EXPORT\n\" \$3 \" crypto_${OPER}_${PRIM}_\" tolower(\$1) \"(void);\n\" }" | awk '{printf("%s\\n", $0)}'); awk "/SODIUM_EXPORT/ && !x {printf(\"$DEFS\"); x=1} 1" < src/libsodium/include/sodium/crypto_${OPER}_${PRIM}.h | sponge src/libsodium/include/sodium/crypto_${OPER}_${PRIM}.h; done

[stouset]

Whoops, slight problem. Hold off for a moment.

[stouset]

Good to go! 👍

[stouset]

Apparently not. The new source files generate object files that conflict with existing ones. What do you suggest I rename them to? s/$operation_$primitive.c/crypto_$operation/$primitive.c?

[jedisct1]

Which ones are conflicting?

[stouset]

Check the Travis build and it'll show you. I just ran out to lunch.

[jedisct1]

One way to solve this is probably to rename implementation files to include the implementation name.
Like stream_aes128ctr_ref.c instead of stream_aes128ctr.c.

[stouset]

It's your project, but I feel like it makes sense to the implementation folders themselves untouched from their original state in NaCl.

[jedisct1]

Renaming the files doesn't change the content.

NaCl uses the same file names for all implementations of a given primitive. That's fine with the build system it was using, but it doesn't play well with autotools if we want to limit recursion.
As long as files are named in a consistent way, there's nothing wrong with renaming them.

[stouset]

By the time you replied, I'd already named the files to $operation_$primitive_api.c. I hope that's alright.

I've also added functions for the remaining constants that weren't handled correctly by the automated script. Pending confirmation from Travis, this is (hopefully) ready to be merged.

[stouset]

Please let me know if I've missed any stylistic conventions you'd like me to follow.

[stouset]

@jedisct1 What's left on this to do before it's mergeable?

[jedisct1]

Hi Stephen,

Sorry, I didn't have time to review it last weekend. But it looks good. I'll review it and merge it as soon as possible.

[jedisct1]

Merged! Thanks a lot for your help!

[stouset]

👍

[stouset]

Any chance this will be released in a version 0.4.2 sometime soon?

[jedisct1]

Sure, I'll try to work on it next weekend.

[stouset]

👍

[stouset]

Any word on a new release? This would make my life somewhat easier for continuous integration.

[jedisct1]

0.4.2 has been released already :)

[stouset]

HA!

[jedisct1]

Yep, thanks for your help, bro!