Re: Remote EOF and MinGW builds

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

Hi Thomas,


> Further more channel_poll() seems to be slightly broken in 0.4x. This is
> fixed on the trunk. After applying/backporting the channel_poll()
> changes from the Changeset (
> http://dev.libssh.org/changeset/514ab6eed2b520d14a1dce783e3180db11f460a4
> ) it seems to work fine
I'll check if I can cherrypick it for the 0.4 branch
> 
> Last but not least, channel_is_eof() might contain a bug. But I am not
> too sure about it. Currently a remote EOF is suppressed until the read
> buffers are empty. I think it would be better if a remote EOF is
> returned immediately, but this might break something.
This is the documented behaviour, and is consistent with the way
streams are handled in posix environments. It makes no sense to
discover that a EOF was received and/or read socket is closed before
the data has been read, thus the delayed EOF.
I wouldn't think returning the EOF value while data are buffered would
be consistent. People using the return value as an indicator of end of
stream would have problems.

> int channel_is_eof(ssh_channel channel)
> {
>   // An remote eof wins!
>   if (channel->remote_eof)
>     return SSH_EOF;
> [...]
I understand you may want to discover if a EOF was sent from the other
side as soon as it happens. Right now, I do not agree with this patch
for the reasons I exposed, but I am open to any possible improvement at
the moment that I understand what you're really trying to do. What have
you got in mind ?

Thanks,

Aris