The caveat is needed because if you include one of these headers on a system that defines rsize_t without having the correct incantations in your configure.ac, you are going to have a bad time. But there is no good general solution to the problem.
- The API has changed so that the function now writes its output into a caller-provided buffer, in a style similar to libcryb-enc.
- All parameter values are now correctly percent-encoded.
- The issuer parameter is now supported.
- The API has been redesigned so the caller is now responsible for allocating storage.
- A few more macros and typedefs have been added to clean up the namespace.
- Key parameter validation has been strengthened.
We can read the issuer from a URI (as a separate parameter, not as a prefix to the label) and store it, but not yet output it. That will be implemented in a future rewrite of oath_key_to_uri().
This was harmless as it would either fall through to an empty default statement (if CRYB_COVERAGE was defined) or out of the switch, but it's still bad style.
When cryb-test is used as a framework for another project, the compile-time test is useless since cryb-test itself will have been built with coverage disabled. Besides, it is not a reliable indicator of whether leak detection will work. Instead, check if the heap is already dirty when we first gain control.
Travis forces _FORTIFY_SOURCE, which enables warn_unused_result annotations in glibc. Some of those annotations are of dubious value; in the case of asprintf(3) and vasprintf(3), they flag code that doesn't check the return value as unsafe even if it checks the pointer instead (which is guaranteed to be NULL in case of failure, and arguably more useful than the return value). Unfortunately, gcc intentionally ignores (void) casts, so we have no choice but to quench the warning with -Wno-unused-result. However, some of the compilers we wish to support don't recognize it, so we move it from the developer flags to the Travis environment.
While there, switch Travis from Precious to Trusty.
The count we passed to memcmp() in mpi_eq() and mpi_eq_abs() was actually the number of significant words in the MPI, rather than the number of bytes we wanted to compare. Multiply by 4 to get the correct value.
To make the intent of the code more apparent, introduce a private MPI_MSW() macro which evaluates to the number of significant words (or 1-based index of the most significant word). This also comes in handy in mpi_{add,sub,mul}_abs().
Add a couple of test cases which not only demonstrate the bug we fixed here but also demonstrate why we must compare whole words: on a big-endian machine, we would be comparing the unused upper bytes of the first and only word instead of the lower bytes which actually hold a value...
In my eagerness to eliminate a branch which is taken once per 2^38 bytes of keystream, I forgot that the state words are in host order. Thus, the counter increment code worked fine on little-endian machines, but not on big-endian ones. Switch to a simpler (branchful) solution.
We failed to clear the negative flag when handling trivial cases, so if one of the terms was 0 and the other was negative, the result would be an exact copy of the non-zero term instead of its absolute value.
