Promote scrypt_kdf to a true symbol

[ivb-supercede]

Apologies if there's a good reason for not doing this, I'm not much of a C interface programmer.

I'm currently writing a Haskell wrapper around libscrypt-kdf which calls out to scrypt_kdf. The library works great - but I was beating my head against a wall trying to figure out linking errors from binding to (what I thought was) the scrypt_kdf function. It was only after checking the library symbols, and reading the code that I realised that scrypt_kdf only exists for the purpose of the header, and my code had to bind to crypto_scrypt.

I assume this symbol is stable, and I could manually write a binding to it that wouldn't break on new versions of scrypt - but I wanted to use the API the "right" way, with the define. Luckily, Haskell has support for relying on C preprocessor directives, and my code can do that. But in general, I think that would be painful. Could scrypt_kdf be somehow promoted to being a proper symbol in libscrypt-kdf to simplify linking for FFIs in the future?

[cperciva]

We could do that, but I was concerned about causing problems with code which already defines a scrypt_kdf function -- libscrypt-kdf is a relatively new addition to the scrypt codebase and people had been packaging up scrypt code and including elsewhere in a variety of ways for many years. The define route ensured that we wouldn't have any symbol collisions.

[gperciva]

Hi @ivb-supercede,

Thanks for asking! We're always happy to hear from people using scrypt.

There's been no action for 3 weeks, and Colin's answer makes sense to me, so I'm going to go ahead and close this issue.