Open XVilka opened 2 years ago
i agree, but do we also need api for switching bins etc.. ?
I am a little bit confused before getting to it and I would really appreciate the further explaination. We are not going to remove the concept of core->block
, right? Just wanna make the access of core->block
more easily. For example, for the proposed API RZ_API bool rz_core_io_read_at(RzCore *core, ut64 offset, ut64 *read)
, offset
means the offset against the start of current core->block
and read
is a buf to store all content of core->block
from the offset
to the end of core->block
?
Or RZ_API bool rz_core_io_read_at(RzCore *core, ut64 offset, ut64 *read)
is used to directly read the binary under test? But how to decide the length of reading? @XVilka
@PeiweiHu idea is to not expose core->block
or similar APIs to 99% of those API users - both external and internal. Splitting into blocks, caching reads, etc, should be done opaquely under the hood. We could only keep the way to change the block size and or/cache size via separate APIs, but that's it.
So, for example, if we have a 64Gb file, the user should be able to read/write to any address via single API call without understanding the current block, the local cache content, etc.
But how to decide the length of reading?
Sorry, I forgot to add ut64 len
parameter to both functions, my bad.
To avoid the need of manually keeping it in mind when using the API.
Should use the transparent RzIO and RzCore API without the need to work with block or blocksize
I propose the new API that will handle all reads and writes itself:
RZ_API bool rz_core_io_read_at(RzCore *core, ut64 offset, ut64 len, ut64 *read)
RZ_API bool rz_core_io_write_at(RzCore *core, ut64 offset, ut64 len, ut64 *written)
See https://github.com/rizinorg/rizin/pull/2694