Hi Yang,

Sorry I didn't see your email before my patch today - but for some reason
Outlook put you in my junk folder :(

> Pushed your last patch with a couple of edits. Sync with github repo.

Cheers .

> Current interface of Curl_base64_encode and
> Curl_base64_decode have a slight glitch in a marginal case. The
> caller of these cannot know if a zero result from the function call
> is due to an out of memory condition or due to a zero length
> encoding or decoding.

Yes - I had noticed that ;-)

> Without modifying Curl_base64_* right now, we have two options
> here...
>
> [..]
>
> As soon as other protocols ;-) start using the result of all this...
> Option 1 is a better refactoring result.

Yes I agree option 1 is the better solution. Having, http_ntlm, smtp, pop3
(which I hope to work on later), etc... all call
Curl_ntlm_create_typeX_message() and then call Curl_base64_encode() is not
only long winded for the developer but also less efficient especially if
each one has their own temporary ntlm buffer.

> Option 2 is easier to achieve right now, given that part of the existing
code would not move.

Arrgghh - That means I've got to rework my patch :(

S.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-08-11