-/*
- * Generic buffered I/O. You supply hooks to be called for low-level operations
- * (swapping of buffers, seeking and closing), we do the rest.
- *
- * Buffer layout when reading:
- *
- * +----------------+---------------------------+
- * | read data | free space |
- * +----------------+---------------------------+
- * ^ ^ ^ ^
- * buffer bptr bstop bufend
- *
- * After the last character is read, bptr == bstop and buffer refill
- * is deferred to the next read attempt. This gives us an easy way
- * how to implement bungetc().
- *
- * When writing:
- *
- * +--------+--------------+--------------------+
- * | unused | written data | free space |
- * +--------+--------------+--------------------+
- * ^ ^ ^ ^
- * buffer bstop bptr bufend
- *
- * Dirty tricks:
- *
- * - You can mix reads and writes on the same stream, but you must
- * call bflush() in between and remember that the file position
- * points after the flushed buffer which is not necessarily the same
- * as after the data you've read.
- * - The spout/refill hooks can change not only bptr and bstop, but also
- * the location of the buffer; fb-mem.c takes advantage of it.
- * - In some cases, the user of the bdirect interface can be allowed to modify
- * the data in the buffer to avoid unnecessary copying. If the back-end
- * allows such modifications, it can set can_overwrite_buffer accordingly:
- * * 0 if no modification is allowed,
- * * 1 if the user can modify the buffer on the condition that
- * the modifications will be undone before calling the next
- * fastbuf operation
- * * 2 if the user is allowed to overwrite the data in the buffer
- * if bdirect_read_commit_modified() is called afterwards.
- * In this case, the back-end must be prepared for trimming
- * of the buffer which is done by the commit function.
- */
+/***
+ * === Internal structure [[internal]]
+ *
+ * Generally speaking, a fastbuf consists of a buffer and a set of callbacks.
+ * All front-end functions operate on the buffer and if the buffer becomes
+ * empty or fills up, they ask the corresponding callback to handle the
+ * situation. Back-ends then differ just in the definition of the callbacks.
+ *
+ * The state of the fastbuf is represented by a `struct fastbuf`, which
+ * is a simple structure describing the state of the buffer (the pointers
+ * `buffer`, `bufend`), two front-end cursors (`bptr`, `bstop`), position in the file (`pos`)
+ * and pointers to the callback functions.
+ *
+ * The buffer can be in one of the following states:
+ *
+ * 1. Flushed:
+ *
+ * +----------------+---------------------------+
+ * | unused | free space |
+ * +----------------+---------------------------+
+ * ^ ^ ^
+ * buffer <= bptr == bstop (pos) <= bufend
+ *
+ * * If `bptr == bstop`, then there is no cached data and
+ * the fastbuf is ready for any read or write operation.
+ * Position of the back-end's cursor equals the front-end's one.
+ * * The interval `[bstop, bufend]` can be used by front-ends
+ * for writing. If it is empty, the `spout` callback gets called
+ * upon the first write attempt to allocate a new buffer.
+ * * When a front-end needs to read something, it calls the `spout` callback.
+ * * Any of the pointers can be NULL.
+ *
+ * 2. Reading:
+ *
+ * +----------------+---------------------------+
+ * | read data | unused |
+ * +----------------+---------------------------+
+ * ^ ^ ^ ^
+ * buffer <= bptr <= bstop (pos) <= bufend
+ *
+ * * If we try to read something, we get to the reading mode.
+ * * No writing is allowed until a flush operation. But note that @bflush()
+ * will simply set `bptr` to `bstop` and it breaks the position of the front-end's cursor.
+ * * The interval `[buffer, bstop]` contains a block of data read by the back-end.
+ * `bptr` is the front-end's cursor which points to the next character to be read.
+ * After the last character is read, `bptr == bstop` and the `refill` callback
+ * gets called upon the next read attempt to bring further data.
+ * This gives us an easy way how to implement @bungetc().
+ *
+ * 3. Writing:
+ *
+ * +---------+--------------+-------------------+
+ * | unused | written data | free space |
+ * +---------+--------------+-------------------+
+ * ^ ^ ^ ^
+ * buffer <= bstop (pos) < bptr <= bufend
+ *
+ * * This schema corresponds to the situation after a write attempt.
+ * * No reading is allowed until a flush operation.
+ * * The `bptr` points at the position where the next character
+ * will be written to. When we want to write, but `bptr == bufend`, we call
+ * the `spout` hook to flush the data and get an empty buffer.
+ *
+ *
+ * Rules for back-ends:
+ *
+ * - Front-ends are only allowed to change the value of `bptr`, some flags
+ * and if a fatal error occurs, then also `bstop`.
+ * - `buffer <= bstop <= bufend`.
+ * - `pos` should be the position in the file corresponding of the location of `bstop` in the buffer.
+ * - Failed callbacks (except `close`) should use @bthrow().
+ * - Any callback pointers may be NULL in case the callback is not implemented.
+ * - Callbacks can change not only `bptr` and `bstop`, but also the location and size of the buffer;
+ * the fb-mem back-end takes advantage of it.
+ *
+ * - initialization:
+ * * out: `buffer <= bptr == bstop <= bufend` (flushed)
+ *
+ * - `refill`:
+ * * in: `buffer <= bptr == bstop <= bufend` (reading or flushed)
+ * * out: `buffer <= bptr < bstop <= bufend` (reading)
+ *
+ * - `spout`:
+ * * in: `buffer <= bstop <= bptr <= bufend` (writing or flushed)
+ * * out: `buffer <= bstop <= bufend` (flushed)
+ * * `bptr` is set automatically to `bstop`.
+ * * If the input `bptr` equals ` bstop`, then the resulting `bstop` must be lower than `bufend`.
+ *
+ * - `seek`:
+ * * in: `buffer <= bstop == bptr <= bufend` (flushed)
+ * * out: `buffer <= bstop <= bufend` (flushed)
+ * * `bptr` is set automatically to `bstop`.
+ *
+ * - `close`:
+ * * in: `buffer <= bptr == bstop <= bufend` (flushed)
+ * * `close` must always free all internal structures, even when it throws an exception.
+ *
+ ***/