On Wed, 31 Mar 2010, Ben Greear wrote:

>> I don't understand. How did your version differ then? It used the same
>> callback, only requiring an extra option first before it did so, or what
>> did I miss?
>
> Existing applications wouldn't set the force flag, so it would never use any
> callback for telnet. Since telnet had always hard-coded it's output to be
> stdout, this made my patch work exactly like the old code did UNLESS you set
> the force flag.

Yes, but I consider the forced use of stdin and stdout to be a bug or a
misfeature so changing that would only make things more like the way they
should be. Not to mention that telnet is next to useless in the shape it
currently uses stdin and stdout...

>> First, you _can_ compare function pointers just fine, but you could also
>> just set a variable where CURLOPT_READFUNCTION is set to make it hold the
>> knowledge if a custom or the internal callback is used. But do we really
>> need that?
>
> Setting the flag in READFUNCTION manipulation doesn't keep us from pointer
> comparison, because maybe user tries to set it back to defaults...so we'd
> have to check for the default 'fread' method regardless.

The only way a user can set READFUNCTION is to use curl_easy_setopt() and the
only way it can restore it to the default internal function is using the same
option (with a NULL argument) so we can indeed store a "default-read-callback"
state for such a purpose if we deem it valuable.

> If you don't mind the potential backwards-compat problems, we can just do
> method pointer comparison in telnet.c. I had that working in an
> un-published patch..before I realized the backwards-compat issue.

As long as when _not_ using any set callbacks it would behave closely to how
it worked before I'm fine with it.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html