search

radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.35k stars 2.97k forks source link

Consider removing esil_inc and esil_dec #17029

Open condret opened 4 years ago

condret commented 4 years ago

For the sake of simplicity, I'd like to remove ++, --, ++=, --=, ++=[] and --=[] from esil. Opinions please

condret commented 4 years ago

I'm especially asking for the opinion of @trufae @thestr4ng3r and @XVilka

XVilka commented 4 years ago

Makes sense, but will require changes across all r2 plugins.

condret commented 4 years ago

I'd do that change. But the tests scare me

unixfreaxjp commented 4 years ago

I'd do that change. But the tests scare me

@condret I am OK with it.

just a FYI, my testbeds are not CI and performing ESIL check but it is using much simpler operations so it is unaffected to your plan, and also on my point of operational analysis, I don't see any problem, except for they who do CTF maybe?

trufae commented 4 years ago

it depends where you put the simplicity focus on. the one typing the esil expression or the vm itself. also can you git grep to find out how many use cases of those commands are currently in use.

thestr4ng3r commented 4 years ago

Since ESIL isn't meant to be a read or written by humans, I have no objection against removing this unnecessary sugar.

trufae commented 4 years ago

i think we can have an esil preprocessor that provides such high level constructions to compile down to something more verbose. but at the end the more instructions we execute the slower esil will be. so imho removing this will make the esil vm simpler, but also slower and will make programmers life harder

And yes, ESIL is meant to be read and written by humans. It's just picky about which humans can read it.

condret commented 4 years ago

it's a tradeoff, I'd prefere having less esil operations and instead longer esil-expressions. Every esil-operation needs to be implemented at least twice. one time for emulation and the other implementation is for dfg, the less operations we have, the less effort is needed for creating graphs (and hopefully analysis) from esil