#17868: base64_decode_nopad() destination buffer length problem --------------------------------------------+------------------------------ Reporter: dgoulet | Owner: nikkolasg Type: defect | Status: Priority: Medium | needs_revision Component: Core Tor/Tor | Milestone: Tor: Severity: Normal | 0.2.9.x-final Keywords: review-group-4, review-group-6 | Version: Parent ID: | Resolution: Reviewer: dgoulet | Actual Points: | Points: 0.1 | Sponsor: SponsorR-can --------------------------------------------+------------------------------
Comment (by nikkolasg): In order to make it API consistent, I had to change also the `base64_encode{_nopad}` structure. That way, it's possible to use the size given by `base64_encode_size` (before, `base64_encode` used implicitely the `base64_encode_size` in both cases). See the tests in `test_util_format_base64_encode_size{_nopad}` which test the "full API from a-to-z". There's a few inconsistencies I did not solve right here (but it's easily resolvable): * `base64_encode_nopad` does not take any flags parameters while we have now a `base64_encode_size_nopad` with a flag parameter. * `base64_encode` expects `char *` but `base64_encode_nopad` expects `uint8_t *`. You can find the branch `base64_nopad` in my github repo [https://github.com/nikkolasg/tor/tree/base64_nopad] Ask for a patch if preferable. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17868#comment:27> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs