Re: Base64 encoding on Leopard
Re: Base64 encoding on Leopard
- Subject: Re: Base64 encoding on Leopard
- From: Quinn <email@hidden>
- Date: Tue, 20 Nov 2007 10:46:06 +0000
At 21:06 -0500 19/11/07, Jaime Magiera wrote:
- Has anyone experienced problems with this call on Leopard? It
works fine on Tiger.
It seems that the function signature for Curl_base64_encode has
changed between the version that shipped with 10.4 and the version
that ships with 10.5. The 10.4 prototype is:
size_t Curl_base64_encode(
const char * inp,
size_t insize,
char ** outptr
);
The 10.5 prototype is:
size_t Curl_base64_encode(
struct SessionHandle *data,
const char * inp,
size_t insize,
char ** outptr
);
Looking at the code snippet you posted, it seems to assume the 10.4
prototype. Hence the crash: you're not provided it with the "data"
parameter.
If this was an official API, I'd consider it to be a major binary
compatibility bug. However, it seems that Curl_base64_encode is not
a public API for libcurl. Specifically, it doesn't show up in any
header that we ship with our developer tools:
$ grep Curl_base64_encode -r /usr/include/
$ # no matches
"Connection.framework" should not be calling non-exported functions
from the system's version of libcurl.
- What are other folks using to get Base64 data?
That's a good question. There are lots of different implementations
in the system, but it's hard to recommend one that's truly
appropriate. For something as trivial as base64, I'd probably just
write it myself (or cut'n'paste the code from an appropriate source,
that is, one with a permissive licence).
btw I filed a bug <rdar://problem/5608839> requesting a nice, general
purpose base64 encode/decode API.
* * *
IMPORTANT: As a general warning for everyone, please don't call
system libraries for which we don't ship headers, or call routines
within a system library where that routine isn't listed in a shipping
header. For example:
o It is safe to use libcurl, because Apple ships <curl/curl.h> as
part of our system headers. We will do our utmost to ensure binary
compatibility for libraries whose headers we ship.
o It is /not/ safe to use routines exported by "libicucore", even
though ICU is an open source API and you could get the headers off
the 'net. Because we don't ship the headers for ICU, we don't try to
maintain "libicucore" in a binary compatible fashion.
In situations like this, if you need a copy of ICU in your product,
statically link in a copy (or, if you need to share it between
multiple processes, build it as a private framework with a nice
unique name).
o Similarly, if a routine is visible in header that we ship, we'll
work hard to maintain binary compatibility for that routine. But if
you snarf the prototype from the source and just call it, you're
likely to run into trouble down the track.
Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden