On Tue, 08 Dec 2015 19:34:39 +0200 Marko Rauhamaa <[email protected]> wrote: > Mark H Weaver <[email protected]>: > > > 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).
