chicken-hackers
[Top][All Lists]
Advanced

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

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


From: Christian Kellermann
Subject: Re: [Chicken-hackers] [PATCH] Fix for #568
Date: Thu, 14 Feb 2013 16:34:23 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

* Peter Bex <address@hidden> [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



reply via email to

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