Wuffs per se doesn't have the ability to read or write to files or network connections. Recall that Wuffs is a programming language for writing libraries, not applications, and that having fewer capabilities means that it's trivial to prove that you can't misuse a capability, even when given malicious input.
Instead, the code that calls into Wuffs libraries is responsible for
interfacing with e.g. the file system or the network system. An io_buffer is
the mechanism for transferring data into and out of Wuffs libraries. For
example, when decompressing gzip, there are two io_buffers: the caller fills
a source buffer with e.g. the compressed file's contents and the callee (the
Wuffs library) reads compressed bytes from that source buffer and writes
decompressed bytes to a destination buffer.
An io_buffer is a slice of bytes
(the data, a ptr and len) with additional fields (the metadata): a read
index (ri), a write index (wi), a position (pos) and whether or not it is
closed.
Writing to an io_buffer, e.g. copying from a file to a buffer, increments
wi. The buffer is full for writing (no more can be written) when wi equals
len. Writing does not have to fill a buffer before further processing.
Reading from an io_buffer, e.g. copying from a buffer to a file, increments
ri. The buffer is empty for reading (no more can be read) when ri equals
wi. Reading does not have to empty a buffer before further processing.
An invariant condition is that ((0 <= ri) and (ri <= wi) and (wi <= len)).
Having separate read and write indexes simplifies connecting a sequence of
filters or processors with io_buffers, similar to connecting Unix processes
with pipes. Each filter reads from the previous buffer and writes to the next
buffer. Each buffer is written to by the previous filter and is read from by
the next filter. There's no need to flip a buffer between reading and writing
modes. Nonetheless, io_buffers are generally not thread-safe.
Continuing the "decompressing gzip" example, the application would write to
the source buffer by copying from e.g. stdin. The Wuffs library would read
from the source buffer and write to the destination buffer. The application
would read from the destination buffer by copying to e.g. stdout. Buffer
space can be re-used, via compaction (see below), so that neither the source
or destination data needs to be entirely in memory at any point.
For example, an io_buffer of length 8 could have 4 bytes available to read
and 1 byte available to write. If 1 byte was written, there would then be 5
bytes available to read. Visually:
[.. .. .. .. .. .. .. ..]
|<- ri ->| | |
|<------- wi ------->| |
|<-------- len -------->|
An io_buffer is a sliding window into a stream of bytes. Its position (pos)
is the number of bytes in the stream prior to the first element of the slice.
The total number of bytes read from and written to the stream are therefore
(pos + ri) and (pos + wi).
While every slice element is in-memory, the stream's prior bytes do not
necessarily have to be in-memory now, or have been in-memory in the past. It is
valid to open a file, seek to the 1000'th byte and start copying from there to
an io_buffer, provided that pos was also initialized to 1000.
The closed field indicates that no further writes are expected to the
io_buffer. When copying from a file to a buffer, closed means that we have
reached EOF (End Of File).
For example, decoding a particular file format might, at some point, expect at
least another 4 bytes of data, but only 3 are available to read. If closed is
false, this isn't necessarily an error, since an io_buffer holds only a
partial view of the underlying data stream, and more data might be forthcoming
but not yet buffered. If closed is true, it is definitely an error.
It is possible to decrement ri or wi, undoing previous reads or writes,
provided that the invariant ((0 <= ri) and (ri <= wi) and (wi <= len)) holds.
For example, it can be faster on 64 bit (8 byte) systems, if buffer space is
available, to write 8 bytes and then undo 1 byte than to write exactly 7 bytes.
The Wuffs compiler enforces that, during a Wuffs function, ri and wi will
never be decremented (by an undo operation) to be less than the initial values
at the time of the call. When considering a function as a 'black box', the two
indexes can only travel forward, and it is up to the application code (not
Wuffs library) code to rewind the indexes (e.g. by compaction).
Even though ri cannot drop below its initial value, Wuffs code can still
read the contents of the slice before ri (in sub-slice notation,
data[0 .. ri]) and it should still contain the (pos + 0)th, (pos + 1)th,
etc. byte of the stream.
The contents of the slice after wi (in sub-slice notation, data[wi .. len])
are undefined, and code should not rely on its values. When passing an
io_buffer into a function, that function is free to modify anything in
data[wi .. len], for either value of wi before or after the function
returns.
Compacting an io_buffer moves any written but unread bytes (those in data[ri .. wi]) to the start of the buffer, and updates the metadata fields ri, wi
and pos. Equivalently, it moves the sliding window that is the io_buffer as
far forward as possible along the stream.
This generally increases (len - wi), the number of bytes available for
writing, allowing for re-using the allocated buffer memory (the data slice).
Suppose that the underlying data stream's ith byte has value i, and that we
start with ri, wi and pos were 3, 7 and 20. Compaction will
subtract 3 from the first two and add 3 to the last, so that the new ri, wi
and pos are 0, 4 and 23. Note that len, (pos + ri) and (pos + wi)
are all unchanged.
Here are two equivalent visualizations of before and after compaction. The xx
means a byte whose value is undefined (as it is at or past wi).
The first visualization is where the slice is fixed and its contents (its view of the stream) moves relative to the slice:
Before:
[20 21 22 23 24 25 26 xx]
|<- ri ->| | |
|<------- wi ------->| |
|<-------- len -------->|
After:
[23 24 25 26 xx xx xx xx]
|| | |
|<-- wi --->| |
|<-------- len -------->|
The second visualization is where the stream (and its contents) is fixed and the slice (the sliding window) moves relative to the stream:
pos+ri pos+wi
| |
Before: [20 21 22 23 24 25 26 xx]
Stream: ... 18 19 20 21 22 23 24 25 26 27 27 28 29 30 31 ...
After: [23 24 25 26 xx xx xx xx]
| |
pos+ri pos+wi
Recall that Wuffs code has limited capabilities, and cannot seek in the
underlying I/O data streams per se. When it needs to seek (e.g. when jumping
between video frames), it will typically provide an "I/O position", a
uint64_t value, via some package-specific API. The application (the caller of
the Wuffs code) is then responsible for configuring an io_buffer whose
(pos + ri) or (pos + wi) value, depending on whether we're reading or
writing, is at that "I/O position".
If the underlying file (or equivalent) isn't seekable, e.g. it's /dev/stdin
instead of a regular file, then the request cannot be satisfied. The
application should then decide whether that error is recoverable or fatal. This
is the application's responsibility, not the library's, as the application
usually has more context to make that decision.
If that "I/O position" is already within the sliding window, it might not be
necessary to seek in the underlying file, as it may be possible to e.g. simply
decrement ri to reach a target (pos + ri), for the reading case. Otherwise,
the typical process is:
- Set
ri,wiandposto0,0and that "I/O position". This discards any buffered data (but does not free the buffer's memory). - Seek in the underlying file to that same "I/O position".
- Copy from the underlying file to the
io_buffer, incrementingwi.
Whether or not it was necessary to seek and copy from the underlying file, when
calling back into the Wuffs library, it typically checks that the io_buffer's
(pos + ri) is now at the expected "I/O position".
An io_buffer is the mechanism for transferring data between the application
and the Wuffs library. Application code can manipulate an io_buffer's fields
as it wishes (but is responsible for maintaining the invariant condition).
Wuffs library code places a further restriction that io_buffers are used
exclusively either for reading or for writing, as optimizing incremental access
to an io_buffer's data, while enforcing invariants, is simpler when only one
of ri and wi can vary.
Wuffs code therefore refers to either a base.io_reader or base.io_writer,
both of which are essentially the same type (an io_buffer) with different
methods. Wuffs code does not reference an io_buffer directly.
An io_bind block temporarily adapts a slice of bytes as an io_reader or
io_writer. This is typically done to call other functions that take an
io_reader or io_writer as an argument.
var r : base.io_reader
var s : slice base.u8
etc
// Just before the io_bind, r's state is saved.
io_bind (io: r, data: s) {
// At the top of the block, r's data slice is set to s, and r's metadata is
// set so that ri = 0, pos = 0 and closed = false.
//
// Because r is an io_reader, not an io_writer, the wi metadata field is
// set to the slice length, not 0.
//
// r must be a local variable, but s can be an expression.
etc
}
// Just after the io_bind, r's state is restored.