Re: `scm_c_read ()' and `swap_buffer' trick harmful

[Neil Jerram]

2008/11/15 Ludovic Courtès <address@hidden>:
>
> 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