[Chicken-hackers] [PATCH] Do not reset string size upon closing string output ports (R7RS compat)

[Peter Bex]

Hi all,

I noticed a bug in the R7RS egg's implementation of call-with-port,
which lead me to fix it and write a test, only to discover another
problem in core.

For some reason if a string port is closed, the yielded string's
length gets set to the buffer size, which means if you request the
string after closing the port, you get the string padded with lots
of spaces.

Now you could say you shouldn't be trying to extract strings from
string ports that are already closed, and perhaps I'd normally agree.
But in order to make the R7RS call-with-port usable, I think we really
need to support this.  For example, otherwise a simple call like
(call-with-output-string FOO) *could* break if FOO happens to be a
user-supplied procedure.  The user then needs to know that his output
is being redirected to a port, otherwise he can't use call-with-port.
This breaks compositionality badly.

The attached patch fixes this weird case.  If someone knows why the
output string's length is being reset, please let me know.
By the way, neither SRFI-6 nor the R7RS spec say anything about the
effect of get-output-string on a string port that has been closed
already, so I guess we have to assume it should be allowed.

I've also added a patch to the "test.scm" so that it prints the
expectations and results with WRITE rather than DISPLAY.  This aids
in debugging.  Without this it was rather hard to see the padding,
since they are all spaces.

Cheers,
Peter
-- 
http://www.more-magic.net

0001-Use-write-for-printing-expectation-and-result-for-be.patch
Description: Text document

0002-Do-not-reset-string-size-upon-closing-a-string-outpu.patch
Description: Text document