Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
base64: switch to libsodium implementation #1786
This PR switches users of the base64 implementation that we borrowed from munge over to the one in libsodium per discussion in #1775.
One thing that's slightly different about the libsodium implementation is that on decoding (base64 to bin), it does not implicitly pad with a
Another difference is that there is no function in libsodium for computing the decoded size in advance so the exact buffer size can be allocated. I used a value of
Finally error handling is a bit different. The encode function always succeeds, which is expected since the buffer is pre-allocated of a size computed by libsodium. If you manage to pass a buffer that is too small, then libsodium internally calls its
Docs and configure are updated for the new external dependency. The Docker builds for travis were already installing it.
This was referenced
Oct 31, 2018
@@ Coverage Diff @@ ## master #1786 +/- ## ========================================== - Coverage 79.66% 79.58% -0.08% ========================================== Files 187 186 -1 Lines 34724 34560 -164 ========================================== - Hits 27662 27504 -158 + Misses 7062 7056 -6
OK I made that change and forced a push. Macro is documented as follows. @dun, I pilfered some of your words, hope you don't mind.
/* Maximum size of buffer needed to decode a base64 string of length 'x', * where 4 characters are decoded into 3 bytes. Add 3 bytes to ensure a * partial 4-byte chunk will be accounted for during integer division. * This size is safe for use with all (4) libsodium base64 variants. * N.B. unlike @dun's base64 implementation from the munge project, * this size does not include room for a \0 string terminator. */ #define BASE64_DECODE_SIZE(x) ((((x) + 3) / 4) * 3)