[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-janitors] #568: read-line produces inconsistent results on DOS-
From: |
Chicken Trac |
Subject: |
[Chicken-janitors] #568: read-line produces inconsistent results on DOS-style line endings when buffer is cut off at an unfortunate point |
Date: |
Sun, 17 Apr 2011 13:18:16 -0000 |
#568: read-line produces inconsistent results on DOS-style line endings when
buffer is cut off at an unfortunate point
----------------------------+-----------------------------------------------
Reporter: sjamaan | Owner: felix
Type: defect | Status: new
Priority: critical | Milestone: 4.7.0
Component: core libraries | Version: 4.6.x
Keywords: tcp, read-line |
----------------------------+-----------------------------------------------
This showed up when trying to use {{{chicken-install}}}, I got this:
{{{
% /tmp/chicken-snapshot/bin/chicken-install -test coops
retrieving ...
resolving alias `kitten-technologies' to: http://chicken.kitten-
technologies.co.uk/henrietta.cgi
connecting to host "chicken.kitten-technologies.co.uk", port 80 ...
requesting "/henrietta.cgi?name=coops&mode=default&tests=yes" ...
reading response ...
HTTP/1.1 200 OK
Date: Sun, 17 Apr 2011 13:07:39 GMT
Server: Apache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain
reading chunks SIZE: 1 line: "1"
...
Error: (zero?) bad argument type: #f
}}}
Oddly, it worked when I omitted the {{{-test}}} or tried the call-cc
server instead!
It turned out that in {{{setup-download.scm}}} in {{{read-chunks}}} the
value of {{{size}}} was {{{#f}}}. After adding some debugging code I
found out that {{{read-line}}} returned {{{"0\r"}}} instead of the
expected {{{"0"}}}, and {{{string->number}}} failed on that.
The actual problem is in an interaction between unit TCP's code for
reading lines from a TCP port and {{{##sys#scan-buffer-line}}}, which it
calls. The attached code reproduces this issue 100% reliably for me and
triggers what's happening in the kernel on Alaric's machine; it happens to
buffer the output just in such a way that my machine reads only a few
characters exactly in the middle of the \r and \n line ending markers.
This causes ##sys#scan-buffer-line to be invoked like this:
{{{
; read buffer, get two characters in it: "0\r"..
(##sys#scan-buffer-line "0\r" 2 0 ...)
; read buffer, get one character in it: "\n"..
(##sys#scan-buffer-line "\n" 1 0 ...)
}}}
At the first call, the one-character lookahead for a \n following the \r
fails because it's not present in the buffer. At the next call, it forgot
that it encountered the \r in the previous buffer and just returns the
empty string. The \r is never discarded.
This can theoretically happen with other types of buffered ports too, but
so far I think it only happens with TCP ports.
--
Ticket URL: <http://makeabank.com/ticket/568>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.
- [Chicken-janitors] #568: read-line produces inconsistent results on DOS-style line endings when buffer is cut off at an unfortunate point,
Chicken Trac <=