* Use r_buf_size to get the size of a buffer, not the private field
* Use r_buf_seek instead of adjusting the private cur RBuffer field
* use r_buf_read instead of r_buf_read_at(.., cur, ..)
* other r_buf_read_at/r_buf_read
* Fix RBuffer usage in REgg
* Wrong replace with r_buf_resize
* Other r_buf_resize fixes
* style fixes
* other style fixes
* Introduce r_buf_tell API instead of using seek
* other style fixes
* style
* style 2
* write_at(cur) == write
* fixes
* avoid changing test
* Make most RBuffer fields private
* Add some fixme comments
* still use base_priv in some places
* Use r_buf_size to get the size of a buffer, not the private field
* Use r_buf_seek instead of adjusting the private cur RBuffer field
* use r_buf_read instead of r_buf_read_at(.., cur, ..)
* Fix RBuffer usage in REgg
* Introduce r_buf_tell API instead of using seek
* write_at(cur) == write
* Fix onIterMap (divide-and-conquer like USACO Shaping Regions), check return values of every `op` call
* Change return types of r_io_read_at and friends back to `int`
* Fix some analysis tests and others
* Fix mem leaks
This was originally used to cause a seek to the next block prior to
reading such that successive calls to r_core_block_read() would progress
through memory one block at a time. This was broken, though, by commit
452669d94113 ("more cleanup in r_core_block_read") when when it used
`next' to directly calculate the offset rather than via a seek.
Only one call site remains that attempts to read the next block instead
of the current, and this probably was not even observable due to the
"hacky fix" added in commit 3bfa61946eca ("Cleaner pvj, fix tinype load,
and honor 'ao N's").
The current of semantics of `next' appear to be broken and there is very
little dependence on it. If the original behavior should be restored
anywhere, it would be much better to add a new function, or just do the
seek explicitly, rather than parameterizing r_core_block_read() on it.
