Topic HTTP Content-Length
This board is threaded (i.e. has a tree structure). Please use the Reply button of the specific post you are referring to, not just any random button. If you want to reply to the topic in general, use the Post button near the top and bottom of the page.
In Response to Günther
Well, the apparent reason for the ++iBytesToRead; is the Buf.New(iBytesToRead); call that's now gone. (Okay, I didn't actually check whether StdBuf::New works with 0 as parameter, I'm just assuming it doesn't.)
And in theory, read should never return EWOULDBLOCK, because the code just polled the file descriptor. That's obviously an optimistic assumption about the behavior of the operating system, but it should be guaranteed at least on Linux ;-) Regardless, windows has to create the close notification without a read call, or indicate readability with zero data available, because Clonk doesn't read() otherwise.
I'm assuming that we wouldn't want to do a read call with length 0 as the parameter. It should be the correct way to check for EOF, but the classic read loop with a static length doesn't do it, and corner cases tend to have more bugs.
But yeah, the conservative option is to do the read call. It obviously doesn't hurt, and closing the connection is not performance critical for Clonk. It's just that that obnoxious comment taunts me every time I look at that function. The author apparently knew why it was necessary, choose not to tell me, and instead opted to tell me that he wasn't telling. It's insulting.
And in theory, read should never return EWOULDBLOCK, because the code just polled the file descriptor. That's obviously an optimistic assumption about the behavior of the operating system, but it should be guaranteed at least on Linux ;-) Regardless, windows has to create the close notification without a read call, or indicate readability with zero data available, because Clonk doesn't read() otherwise.
I'm assuming that we wouldn't want to do a read call with length 0 as the parameter. It should be the correct way to check for EOF, but the classic read loop with a static length doesn't do it, and corner cases tend to have more bugs.
But yeah, the conservative option is to do the read call. It obviously doesn't hurt, and closing the connection is not performance critical for Clonk. It's just that that obnoxious comment taunts me every time I look at that function. The author apparently knew why it was necessary, choose not to tell me, and instead opted to tell me that he wasn't telling. It's insulting.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill