On 3/20/06, Reed Sheridan <
address@hidden
> wrote:
> Here's a fix for some read-line brokenness. It's fairly well tested with
> the FGETS_INTO_BUFFER flag both on and off.
(pp (with-input-from-string "foo\r" read-line))
==> "foo^@"
read-line did that before my patch. I didn't do anything to non-file input. AFAICT, the old behavior of read-line was:
for file input:
"foo\nmore" -> "foo"
"foo\r\nmore" -> "foo"
"foo" (end of file) -> "fo"
"foo\rmore\n" -> "foo\rmore"
for non-file input:
"foo\nmore" -> "foo"
"foo\r\nmore" -> "foo"
"foo\r" (end of file) -> "foo\r" (as in your example)
"foo\rmore" -> "foomore"
If I understand you correctly, you want readline to terminate a line on \r, \n, or \r\n and not include the separator in the result? This creates difficulties for the fast path because fgets doesn't care about \r.
So to deal with \r as I think you intended, we have a few options:
1. Get rid of the fast path and scan every string for \r, \r\n, and \n in Scheme
2. Include an extended fgets in C that deals with \r
3. Change the specification, which the old implementation didn't come close to following anyway.
If I could have my way and break everybody's code in the process, I would make the separator a parameter and include it in the results, and add a "chomp" function to get rid of separators at the end of a line.
What do you think?
Reed Sheridan