On 03/31/2010 02:41 PM, Daniel Stenberg wrote:
On Wed, 31 Mar 2010, Ben Greear wrote:
So in what way does it not work with that callback?
At the least, it wasn't flushing data promptly to the screen, but
rather was buffering it. If you blindly typed in user-name and
password and hit enter a few times, you could log in..but it wasn't
really usable.
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.
It is assumed that any app setting the force flag is completely
aware that telnet will now write to the callback method and not
to stdout any more.
I was also suspicious that comparing function pointers might not work
in all cases, but that may just be more paranoia (I usually program
other than 'C').
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.
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.
Thanks,
Ben
--
Ben Greear <[email protected]>
Candela Technologies Inc http://www.candelatech.com
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
