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 <greearb_at_candelatech.com>
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