[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nonblocking get-bytevector-n bug?

From: Chris Vine
Subject: Re: Nonblocking get-bytevector-n bug?
Date: Tue, 8 Dec 2015 19:28:07 +0000

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]