Re: Nonblocking get-bytevector-n bug?

[Marko Rauhamaa]

Chris Vine <address@hidden>:

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

Well, none of Guile's blocking I/O routines block when the port is
nonblocking. Thus, they are in dire violation of the strict
interpretation.

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

It seems to me whoever wrote the spec wasn't thinking of nonblocking
ports at all. Are nonblocking ports recognized by RnRS?


Marko