Daniel Stenberg wrote:
> On Tue, 23 Dec 2008, Peter Stuge wrote:
>
>> Why is there even a base64_decode() in libssh2? OpenSSL does b64. Do
>> we have our own because libgcrypt doesn't have it? Hm. It's in GNU
>> crypto stuff for Java, maybe libgcrypt should add it?
>
> I don't see the need even if OpenSSL and the others won't have it. What makes
> libssh2 users particularly interested in this?
>
>> Also it isn't heavily used in libssh2 so we could even change it to let the
>> caller alloc, or to always use malloc, or..
>
> I'd prefer a version that doesn't use malloc at all but leaves that to the
> parent function (malloc is not a real fix since there are systems with
> different memory systems so 'free' cannot free memory a library allocated
> with
> malloc easily anyway).
>
>> I think letting the caller alloc would be the simplest change, it does
>> change how the function works though. Patch welcome?
[...]
I second Peter, because I also wondered why base64 encoding is part of the
library. If it is used internally, there's a reason for implementing
the functionality (for use within the library). But that does not
make it necessarily part of the externally visible library. Additionally
the function set is incomplete: why provide a decoding function, but not
a corresponding facility for encoding data?
In my opinion the cleanest way would be to remove the base64 API functionality
completely in the long term.
On the implementation side (for library-internal use) there is a way to
keep the current interface, while still allowing a user to provide his own
boffer:
if *dest is NULL, memory could be allocated, otherwise the pointer is assumed to
point to at least dest_len bytes.
Making the memory allocation depend on the value of a pointer is known e.g.
from realloc(3).
On the other hand that interface is complicated and error-prone. A better
one would allow a user to provide a buffer:
size_t internal_base64_encode(char *dest, size_t dest_len, const char
*src, size_t src_len);
size_t internal_base64_decode(char *dest, size_t dest_len, const char
*src, size_t src_len);
A related function could help users provide a buffer for the decoded data:
size_t libssh2_base64_decodedlen(const char *src, size_t src_len);
size_t libssh2_base64_encodedlen(const char *src, size_t src_len);
The implementation could be trivial: 3 input bytes will be encoded to 4 output
bytes (RFC 2045).
A user could then use the following lines for decoding base64 data (error
handling omitted):
size_t len;
len = libssh2_base64_decodedlen(encodedbuf, encoded_len);
decodedbuf = malloc(len);
decoded_len = libssh2_base64_decode(decodedbuf, len, encodedbuf,
encoded_len);
assert(decoded_len == len);
Heiner
------------------------------------------------------------------------------
_______________________________________________
libssh2-devel mailing list
libssh2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
