On 01/26/11 15:19, pancake wrote:
yo
On 01/25/11 20:12, Glyn Kennington wrote:
Here's what I've got so far. I've tested the different usages on some
small files of random data (and the multibyte text I was working with
originally), but far from extensively.
I've added a function r_slide to perform the shifting up or down after
the inserted/deleted region. My intention is that this could then be
used by file.insert, when implemented, or another "resize" option that
only moves the bytes around between seek and end-of-block (where the
blocks might be memory pages, or file sections).
the name of the function is wrong. if it's public it should be
r_core_slide()
instead of r_slide(), but i think this function can be 'static' at
this moment.
The thing is that r_slide() should probably take more sense to be in
r_io,
renamed as r_io_shift() (shift better than slide?)
Another modification you should do in r_io_shift() is to work in blocks
before mallocing huge chunks in the heap. This is:
- use local ut8 buf[4096]; or malloc to 64k (if you can do some
benchmarks,
we will see which block size is more optimal (4KB, 64KB, etc..)
- loop reading on this block and writing in the shifted address.
This way r_io_slice() will not fail when low memory or huge shiftings.
note that in this way you should detect overlapping of readed/written blocks
to avoid corrupting data. this also depends in the direction.
The reason is not only to support big blocks, but also because doing big
syscall reads blocks the process in kernel state, making it uninterrupible
and less responsive. In the way I'm proposing to do it you can break the
loop at any point without locking in kernel space for lot of time.
--pancake
_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
