On Thu, 2 Jan 2003, Martin Gasbichler wrote:
> The file doc/io.txt contains a description of the I/O system of Scheme
> 48. It doesn't contain a direct specification of the character
> representation either but it mentions the procedure read-block from
> i/o which can be used to read into a byte-vector. There should
io.txt should mention that the COUNT argument of READ-BLOCK may be
* count integer >= 0 ==> get COUNT bytes/chars, maybe block;
* count = 'any ==> get at least one, maybe block, or more
* count = 'immediate ==> get what's available but don't block.
And that was an unfortunate design decision: the COUNT mixes numbers and
politics, and doesn't let us call for at most n bytes / not blocking, let
alone for at least n0 bytes, possibly blocking, at most n1 bytes, not
blocking. As a result, the READ-STRING!/PARTIAL procedure in scsh/rw.scm
cannot READ-BLOCK the input directly into the argument string, but has to
allocate, copy, and throw away a buffer string. Not really what the !
suggests. Better make READ-STRING/PARTIAL do the reading, and let R-S!/P
call it and copy the result into its argument, than the wasteful other way
By the way, the implementation of R-S!/P in scsh/rw.scm (0.6.3 beta) looks
suspect to me. It basically calls READ-BLOCK with COUNT :=
(if (> (byte-vector-length (port-buffer fd/port)) 1) 'any 'immediate)
Problems may arise when
* the requested #bytes = 0 and the port-buffer is long (COUNT = 'ANY).
RSP should return 0, but may block.
* #bytes > 0 and the buffer-port is short (COUNT = 'IMMEDIATE).
RSP should get at least one character, but may not and return 0, if the
buffer is (zero-sized or) empty and the input device blocks.