WIP: use ut64 for keys/values in ht

[ret2libc]

I'm not particularly happy with the implementation... but it's the only way I've could think of to avoid messy casts all around (e.g. if you want to provide an hashfn, it should accept a ut64 and convert it, if you want to provide a cmp function it should accept a ut64 and convert it, etc.. it is a problem because in that way even for "regular" functions like strdup, strcmp, sdb_hash you would need a wrapper for the casts). With HT_TYPEs, instead, you don't need to do all this. Your custom functions could still accept pointers, if needed.

The bad thing is that in the code there are few switches based on the type of the ht. The good thing is that if you compile it with --buildtype release (which uses -O3) the compiler does a lot of optimization and those switches are actually converted into just one direct call to the function, because actually it's just a matter of type and nothing really changes at the assembly level between the 3 ht_types. (to be honest we should use -O3 in general, because it simplify a lot of static calls, etc.)

[ret2libc]

TODO:

• [ ] test on 32bit
• [ ] test with radare2

[ret2libc]

Some other comments if it wasn't clear from the code (maybe i will add some comments in the header later):

• HT_TYPE_NONE: key is ut64, value is ut64. I don't think we ever need this as-is, but it is like the dict implementation.
• HT_TYPE_P: key is pointer, value is pointer.
• HT_TYPE_U: key is ut64, value is pointer.

I think most of the time we want a pointer for the value. For the key, instead, sometimes you may want to have numbers, other strings or other times something completely different (though it's a rarer case)

[ret2libc]

Actually also -O2 (which should be safe) enables enough optimizations to make all those runtimes checks be translated in one simple call.

[radare]

THis can be closed i think

[radare]

Thanks!

On 12 Nov 2018, at 12:07, Riccardo Schirone notifications@github.com wrote:

Closed #176.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.