get-bytevector-some - read some unspecified number of bytes from a port
(import (rnrs)) ;R6RS
(import (rnrs io ports)) ;R6RS
blocking as necessary, until bytes are available from
or until an end of file is reached.
If bytes become available, returns a freshly allocated bytevector
containing the initial available bytes (at least one), and updates
to point just past these bytes.
If no input bytes are seen before an end of file is reached,
the end-of-file object is returned.
The implementation should allocate a buffer and ask the operating
system to read data into the buffer, then use whatever number of bytes
the operating system wrote into the buffer. This typically does the
right thing on Unix-like systems.
Returns a single value; a bytevector or the end-of-file object.
(define (char-rot13 c)
(cond ((and (char<=? #\a c #\z))
(+ (char->integer #\a)
(mod (+ (- (char->integer c) (char->integer #\a)) 13)
((and (char<=? #\A c #\Z))
(+ (char->integer #\A)
(mod (+ (- (char->integer c) (char->integer #\A)) 13)
;; This example unnecessarily works with binary ports
;; to demonstrate get-bytevector-some.
(let ((in (standard-input-port))
(let lp ()
(let ((bv (get-bytevector-some in)))
(unless (eof-object? bv)
(do ((i 0 (+ i 1)))
((= i (bytevector-length bv)))
(let* ((b (bytevector-u8-ref bv i))
(c (integer->char b))
(b^ (char->integer (char-rot13 c))))
(bytevector-u8-set! bv i b^)))
(put-bytevector out bv)
This procedure is normally used when the port is expected to be
connected to some byte source other than a file and the amount of data
to read is not known in advance. It may be an interactive terminal or
a network connection. The program above can be run interactively and
produce line-by-line output.
Binary input ports are not always the simple streams of bytes they
seem to be. The other end of the port may be connected to a file, in
which case things are relatively simple. But the other end may also be
some type of buffer that is filled in bursts, possibly delimited by
TCP sockets produce data in bursts and end with an infinite sequence
of end-of-file objects (or an I/O error). UDP sockets produce data in
one burst per datagram and can also signal errors via ICMP packets.
Interactive terminals produce data in bursts (one per character or
approximately one per line), and they can also produce end-of-file
objects (typically mapped to Ctrl-D).
The other procedures for reading from binary input ports, i.e.,
specify a length or read all data and block as necessary to read that
number of bytes, or until an end-of-file is received. These procedures
therefore don't work when the data is produced in bursts that are not
separated by end-of-file objects.
This procedure is unique to R6RS and cannot be implemented in terms of
the other standard I/O procedures.
This procedure can raise exceptions with the following condition types:
- &assertion (R6RS)
The wrong number of arguments was passed or an argument was outside its domain.
must be an open binary input port.
- &i/o-read (R6RS)
There was an I/O error during the read operation.
- &i/o-port (R6RS)
This condition specifies the port object related to an
This procedure first appeared in R6RS. It corresponds to the semantics
syscall with some unspecified byte count.
This page is part of the
It includes materials from the RnRS documents.
More information can be found at
Markup created by unroff 1.0sc, March 04, 2023.