chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] [PATCH] Fix for #568


From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Fix for #568
Date: Sun, 3 Feb 2013 20:44:19 +0100
User-agent: Mutt/1.4.2.3i

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.

Cheers,
Peter
-- 
http://sjamaan.ath.cx

Attachment: 0001-Implement-fix-for-568-by-making-sys-scan-buffer-line.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]