2008/11/15 Ludovic Courtès <[EMAIL PROTECTED]>:
>
> So where to go from here? I think this example shows that the
> `swap_buffer' trick is too risky, unfortunately. Thus, we may need to
> revert it, at least in 1.8. Second, I think that a `read' method as a
> replacement for `fill_input', as I proposed back then [3], would be
> safer; maybe 1.9 would be a nice place to add it. Neil: what do you
> think?
I think this means we should only do the swap_buffer trick for
unbuffered ports. That would solve the original problem, and avoid
breaking cases like this.
It _could_ be argued that cbip_fill_input() should take more care to
use the port's actual current buffer. e.g. it should construct a new
R6RS bytevector around the current port->read_buf, and pass that to
the read! procedure. But I'm not going to argue that, because the
generalization of that would be to say that C code that implements a
buffered port cannot assume that the buffer stays as originally set;
and, with hindsight, it seems that C code _should_ be able to rely on
this. (Plus constructing a new bytevector would probably be bad for
performance.)
I recall you queried before whether we should apply this fix to
buffered ports too, and I confidently said yes; sorry about that!
Do you agree that doing the trick only for unbuffered ports would be a
good approach? If so I'll see what that means in terms of code.
Neil
