Re: Temporary build

Um...it's a bit overengineered, isn't it?

(A) Unless the socket is set to non-blocking, the only time that read() will 
return less than the desired number of bytes is on EOF (when the stream is 
closed). If the stream closes before a command finishes reading, you bet we 
shouldn't faff about trying to read the rest of the command! That's what the 
line checking whether the return value is zero is all about.

(B) Even if you were to do that, there's no need to unregister the socket 
like that! The MSN implementation is single-threaded, so as long as control 
doesn't leave that function, there's no possible way that it could be called 
again.

Try that with some debug code. If you ever need more than one try to read 
data except on EOF, I want to hear about it.

Meredydd

On Thursday 10 April 2003 00:08, Colin Leroy wrote:
> On 09 Apr 2003 at 21h28, Meredydd Luff wrote:
>
> Hi,
>
> Attached is a diff of a bugfix in msn.
> Basically the bug is that read() may return having read less than msglen.
> From `man 2 read`:
> 	ssize_t read(int fd, void *buf, size_t count);
> 	read()  attempts  to  read  __up__  to  count  bytes from file
>
> That would leave parts of the message to the standard incoming_handler.
>
> The fix consists in
> .unregister sock (so we are sure the handler won't come up in the way)
> .call read() until we did read msglen bytes (ok 6 times only in order to
> avoid infinite loop when network is really bad)
> .register sock again
>
> HTH,

----------------------------------------
Content-Type: text/plain; charset="us-ascii"; name="msn_core.C.diff"
Content-Transfer-Encoding: 7bit
Content-Description: 
----------------------------------------

-- 

Everybuddy project maintainer
http://www.everybuddy.com/

MSN:     [email protected]
AIM:     blip109
Yahoo:   modula7