You can clone with
HTTPS or Subversion.
Currently, many of the constants used throughout this code are only available as #define. This is okay for C code, but means that constants have to be manually transcribed for an FFI interface. It would be helpful if there were some function(s) that could be called to retrieve this information.
This came up in cryptosphere/rbnacl#49
It definitely makes sense to expose these through functions, in addition to #define. Will do it tomorrow.
This has been done, at least for each operation. Check out the current code and tell me if you need more values exposed!
@jedisct1 will look soon. We just shipped 1.1 with hardcoded constants in Ruby, but for 2.0 we can definitely leverage these
Actually, I found have a problem with the way the current approach is implemented. You appear to provide methods exposing the constant values for each cryptographic primitive (e.g., crypto_auth_bytes, crypto_auth_keybytes), but only for the default implementation.
Part of the original purpose behind this change is to allow wrappers on libsodium to provide backward-compatibility in case one of the default implementations changes. So it would be extremely useful to also have
Obviously not just for the crypto_auth_* family of functions. I'm just using them as an example.
Functions returning constant values have indeed only been implemented for the default constructions.
That's only temporary and only because adding them takes time and I wanted to start with these.
If you want to help with writing the remaining wrappers, your help would be more than welcome!
I'm actually already on it. I'm having trouble getting the project to build from a clean git checkout though. Is there a quick guide to getting it to build?
configure.ac:9: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:11: error: possibly undefined macro: AM_MAINTAINER_MODE
configure.ac:12: error: possibly undefined macro: AM_DEP_TRACK
configure.ac:40: error: possibly undefined macro: AM_PROG_AS
configure.ac:231: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:347: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."
Run ./autogen.sh, it should build everything you need.
One more quick question. I'm hesitant to edit any of the files under crypto_$primitive/$implementation/ref, since those are checksummed and presumedly pristine imports from DJB's NaCl project. But that seems like the most logical place to put them. Where should these definitions go?
ref refers to a specific implementation. I don't think we should expose anything related to a specific implementation. ed25519 is ed25519 and code shouldn't link against a specific implementation. The library will take care of picking a fast one that works.
For constants, it doesn't make any sense to have different functions for each implementation of a primitive. These will hopefully always be the same.
So the best place to add them is probably crypto_$operation/$primitive/$operation_$primitive.c as in crypto_onetimeauth/poly1305/onetimeauth_poly1305.c
Before you replied, I approached it this way. I can do it your way if you prefer, too. I agree that the constants shouldn't differ between implementations. Let me know your thoughts.
The problem with static inline is that the symbols are exported, making the library difficult to use from other programming languages.
Errr... That the symbols are not exported, sorry. But you got the point :)
Note specifically that static is unusable from FFI
D'oh! Take a look at this approach, instead.
That's really cool, bro!
(edited: updated the commit to actually build)
I'll try and automate something, instead of having to type that all out by hand, manually.
Nitpick: if you're only bringing in stdlib.h for the size_t definition, you may want to include stddef.h instead. Both options are valid, of course, but stddef.h should be smaller and more specific.
Good nitpick! The changes have been done.
I've recommitted the change but with stddef.h instead of stdlib.h. Barring any other suggestions, I'm going to try and semi-automate what I've got to hopefully add as many of these as possible without having to do it manually.