* Peter Bex <peter....@xs4all.nl> [130203 20:44]: > Hi all, > > Attached is my third or fourth attempt at fixing bug #568. The bug is > that TCP and pipe-ports in some cases do not drop the \r in a \r\n > sequence. > > What finally made it work was to invert the logic for fetching data and > scanning for newline/carriage return characters and copying strings into > the line. Now the scan-buffer-line is more complicated, while the > port-specific read-line implementations are a little bit simpler. > > This is extremely tricky code, so expect some bugs! I tested the tcp > stuff rather extensively, but I'm still a bit unsure. I also tested > the posix stuff through scsh-process with modified versions of the > client/server programs. > > Once this has been thoroughly tested, I think it should go into the > stability branch because this is a lurking bug which can cause a lot > of weird, hard to reproduce errors. Actually, I'm pretty surprised > we haven't heard of other people running into it! > > There's still one small "problem" and that's what to do when the > user supplies a read-limit L and character L-1 is \r with L being \r > Currently you'll get all characters up until the \r into your string, > and when reading again you'll get an empty line. I think this is > technically correct, but could be somewhat surprising and in practical > situations it might be a cause of pain. For now I just kept it this way.
I think it's all good -> pushed. Cheers, Christian -- In the world, there is nothing more submissive and weak than water. Yet for attacking that which is hard and strong, nothing can surpass it. --- Lao Tzu _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
