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.
Commit 57b199789d6a ("Reread block after undo seek. Fixes dbg.status
issue") reads the *next* block into the buffer rather than the current.
This breaks backwards seeking as can be seen in the following example:
$ r2 -N malloc://0x4000
[0x00000000]> b 64
[0x00000000]> wb 38
[0x00000000]> s 64
[0x00000040]> wb deadbeef
[0x00000040]> s-32
[0x00000020]> px
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000020 dead beef dead beef dead beef dead beef ................
0x00000030 dead beef dead beef dead beef dead beef ................
0x00000040 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00000050 0000 0000 0000 0000 0000 0000 0000 0000 ................
[0x00000020]> s+16
[0x00000030]> px
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
0x00000030 3838 3838 3838 3838 3838 3838 3838 3838 8888888888888888
0x00000040 dead beef dead beef dead beef dead beef ................
0x00000050 dead beef dead beef dead beef dead beef ................
0x00000060 dead beef dead beef dead beef dead beef ................
The first block to a string of ASCII '8' bytes and the second to
0xdeadbeef. We then seek backwards 32 bytes from our current 64 byte
offset but a dump at the resulting offset shows data from half way into
the second block (i.e., offset 0x60.) Dumping again after seeking 16
bytes forward shows the expected last bit of the first block. Clearly
the intent was to reread the current block, not the next block, after an
undo or backward seek.
NOTE: The above example will only work after applying the previous
commit as rereading the buffer when displaying the prompt hides this
bug.
Additionally, since the commit intended to reread the buffer only after
an undo seek, do not do this at all on a backward seek.
This is one of the first steps to improve analysis. This way we'll have
one single place to change if we want to change the meaning of the
"size" field. (size -> realsize)
