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

[Ludovic Courtès]

Hello Neil,

"Neil Jerram" <address@hidden> writes:

> 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.

In theory, yes.  In practice, the notion of "unbuffered port" is
ill-defined, I'm afraid.  The `SCM_BUF0' flag probably can't be relied
on, as it appears to be only really used on `fports.c'.  Actually, for
some reason (probably copy & paste), make_cbip() creates ports with
"SCM_OPN | SCM_RDNG | SCM_BUF0", although `SCM_BUF0' is probably not
needed.  So I think "unbuffered port" means "read_buf_size <= 1".

> 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.)

Exactly: it's nice to be able to avoid the allocation of a new
bytevector.

> I recall you queried before whether we should apply this fix to
> buffered ports too, and I confidently said yes; sorry about that!

No problem.  The port "API" exposes too much internals, which makes it
hard to change it without breaking existing code.

> 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.

I think it *should* work, provided `SCM_BUF0' isn't relied on (at least
for the particular case I'm interested in...).

Thanks!

Ludo'.