On Sat, 25 Oct 2008, Josef Wolf wrote:

> In this spirit, it would be a big win if curl's INTERNALS paper would
> give a _rough_ overview of the used data structures. It don't need to
> be much. Just a couple of lines. Something like

I agree. The INTERNALS document was an effort that never really got updated
much and it's not detailed enough to help a lot. I think a more sensible
approach is perhaps to make sure the comments in the source code are good
enough to more or less explain the same things. They're easier to keep
up-to-date and in sync with the code.

> At first glance it looks like the functionality I am talking about could be
> placed in Curl_http_auth_act(). I guess the two clauses that handle 401/407
> could be extended to retrieve the credentials.

Yeps. That code figures out what auth method to use so it could also get the
credentials.

> But on a second glance, it looks to me like some code and data structures
> could use some refactoring to improve readability. Please don't get
> offended, I am not going to criticize. Chances are that it is hard for me
> to read because I am not familiar with the code and data structures. :-)

Don't worry, I don't think we'll be that easily offended.

I'm quite sure there are improvements to be done in both code and data
structures all over. I'll welcome patches. I'm sure a new pair of eyes and a
fresh interest in the code can shake up both bugs and fixes for them!

> BTW: What is perhepsrewind() good for? Are there limitation in POST/PUT
> that require reconnect?

Yes, it's basically for the case where data is sent in vain since libcurl
knows it will be discarded. The perhepsrewind() then checks if the connection
is then better closed and re-initiated or if it is better off sending over the
data anyway.

> BTW1: While glancing through the code, I stumbled over
>
> /* clear all string pointers first */
> memset(dst->set.str, 0, STRING_LAST * sizeof(char *));
>
> in url.c:Curl_dupset(). This is not guaranteed to work by the
> language (see subclause 2 in http://c-faq.com/null/varieties.html).

Right, but that's a very theoretical limitation (for ancient and most extinct
machines) and I'm convinced we violate it elsewhere as well. Like when doing
calloc() on a struct that contains pointers and then assume they are NULL.

I rather not fight those problems until the day they actually turn out to
cause problems. I suspect that day will never come, seeing that libcurl has
already been ported successfully to a LARGE number of operating systems and
architectures.

-- 
  / daniel.haxx.se