pancake wrote: > >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?)
I didn't want any confusion with bit-shifting, and was thinking about those sliding-tile puzzle games. But if it's in r_io, shift is clear enough. > 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. Good point, that's what I miss when I only consider small files. Do you recommend any benchmarking tools more sophisticated than time(1)? [...] > btw, I plan to organize a hackaton in february, would you like to > participate? Hopefully - the more notice I have, the better chance I have of keeping an evening/weekend free. Glyn _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
