[EMAIL PROTECTED]">Yes it will read the next char, but the readcount is already incremented and so you insert one undefined char in the uri.Quoting Thomas Butter <[EMAIL PROTECTED]>:For example if in line 257:
requestLine.uri[readCount] = (char) buf[pos];
readCount++;
pos++;
buf[pos] is undefined the last fill called by the last read() only got
one byte (which was enough for the last read()).
Yes, but (pos >= count) should be true then (on the next loop iteration), so it
should attempt to read again from the input stream (right ?). I tested that
stream with very small buffers (a 4 bytes internal buffer), so the situation
you described must have happened at some point during my testing.
I think the problem won't be triggered by a small buffer, but by tcp packet that ends 1 byte after the current buffer. If the next packet didn't arrive when fill() is triggered the next time then pos==0 and count==1, the read then does a pos++. You will then read the char at buf[1] which still is the char from the last buffer (and so quite undefined).
[EMAIL PROTECTED]">You are right. It is quite easy to reimplement a BIS.I would volunteer rewriting this class if you agree with my
assumptions.
If extending BIS is indeed a problem, I would vote +1 in duplicating the BIS
code into SocketInputStream, and -1 for layering another IS (for performance
reasons)
[EMAIL PROTECTED]">
-- Thomas Butter <[EMAIL PROTECTED]> ICQ: 891617
"Unix IS user friendly, it is just selective about who his friends are."
