Projects using the legacy API are unlikely to use these new macros.
OTOH, people using the Sodium API would be puzzled about the missing
16 bytes in the secretbox and box APIs.
More importantly, these macros are designed for bindings.
Having these bindings enforce proper limits (for the *_easy API
that they all use) and yet have the underlying library call
sodium_misuse() would be sad.
*_BYTES_MAX constants constants represent the maximum size of
a message.
No accessor functions for now. They will be renamed, as the
*_BYTES_MAX suffix was previously also used for the maximum output
size of stream ciphers.
These macros are designed to be used by language bindings, so they
can perform some sanity checks before calling the sodium API.
Returning the name of an internal function to bindings is useless.
They need way more context to recover from these errors, and
their own backtrace will be way more useful for diagnostics.
This function will eventually be able to call a user-defined hook,
that may be useful to people writing bindings for other languages.
The function will not return, though, and will keep calling
abort() after the hook. So, hooks should not return either.
They should gracefully kill the current process or thread instead.
There are many more abort() instances to replace.
This is long and boring.
A weak function cannot be inlined, but even if it's a little bit
far stretched, a compiler could add code taking different paths
according to the callee.
With a weak function called after the zeroing, we can be sure
that the zeroing has to happen.
`z` being volatile implies more load/store than needed, but this should
be safer if we want to stick with pure C code, and gives us a chance to
zero the registers.
It's still way faster than byte-by-byte comparisons anyway.
Xored secrets don't matter much when compared byte-by-byte, but they
can be more annoying in 128-bit registers.
