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
