2011/8/10 Steve Holme wrote:

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

> So to clarify, are you saying that the calls to Curl_base64_encode () should
> be moved back into Curl_output_ntlm () ?

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.

As a consequence, letting Curl_ntlm_create_type1_message() and
Curl_ntlm_create_type3_message() directly return the result of a
Curl_base64_encode() call only makes things worse.

Without modifying Curl_base64_* right now, we have two options here...

1) Curl_ntlm_create_type1_message() and
Curl_ntlm_create_type3_message() calls Curl_base64_encode() _and_
checks its result and cleans up whatever these have allocated in case
of OOM and returns failure.

2) Curl_ntlm_create_type1_message() and
Curl_ntlm_create_type3_message() do not call Curl_base64_encode() and
the check and clean up is done where it is right now.

As soon as other protocols ;-) start using the result of all this...
Option 1 is a better refactoring result. Option 2 is easier to achieve
right now, given that part of the existing code would not move.

In my previous message I was suggesting option 2. But option 1 should
be better in a not distant future.

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html