Re: Nonblocking get-bytevector-n bug?

[Chris Vine]

On Tue, 08 Dec 2015 19:34:39 +0200
Marko Rauhamaa <address@hidden> wrote:
> Mark H Weaver <address@hidden>:
> 
> > While I'm reluctant to guarantee any fixed limit, I can offer this:
> > the returned bytevector will always be of a manageable size,
> >
> > [...]
> >
> > Would this work for you?  
> 
> It suits my immediate needs, thank you.
> 
> However, I think the whole slew of bytevector I/O could take a more
> relaxed reading of the RnRS spec, which probably was simply worded
> carelessly.

I think better non-blocking RnRS input procedures would be advantageous
for the reasons you have given, but R6RS and R7RS seem to me to be clear
on any reasonable reading: apart from get-bytevector-some they require
blocking behaviour if the request has not been met and end-of-file has
not been reached (as do other comparable things, such as fread())[1].
Otherwise, get-bytevector-some, for all its inadequacies, would not
have been necessary.

I would be very surprised if it was a result of careless wording.

Chris

[1] With the caveat that read-bytevector! will not overrun the
bytevector if no end argument is provided (the end position is
inferred).