#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 --------------------------------------------+------------------------------ Changes (by dgoulet):
* status: needs_review => needs_revision Comment: Replying to [comment:21 nikkolasg]: [snip] > With these two remarks in mind, it seems to me that using `base64_encode_size` for encoding *without* padding is wrong API wise and logic wise. My suggestion would be to introduce a new function `base64_encode_size_nopad` which returns the encoded buffer size without padding. That way, both base64 APIs are being consistent: > * Padding: > * Get the base64 buffer length with `m = base64_encode_size(n)` > * Encode with `base64_encode(encoded,m,plain,n)` > * Decode with `base64_decode(decoded,n,encoded,m)` > * No padding: > * Get the base64 buffer length with `m = base64_encode_size_nopad(n)` > * Encode with `base64_encode_nopad(encoded,m,plain,n)` > * Decode with `base64_decode_nopad(decoded,n,encoded,m)` > > Does it make sense or am I over my head ? > If it does make sense, I'm happy to provide that method once you approve it. It does! It makes a consistent API which makes sense to me. It's symmetric also, so please go ahead! :) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17868#comment:24> 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