Pull request #79 submitted.
On 8/28/14, 10:51, "Shawn Debnath" <sh...@debnath.net> wrote:
>Turns out that when inserting items in xhash, the code stores a pointer to
>the key passed in by the user in the xhash node and uses that later to
>compare in _get. The problem is that it breaks scenarios where the user
>use a temp buffer to build the key, then insert or put it in the xhash
>and then free the buffer memory. Assumption here is that xhash code
>would allocate necessary buffer to store internal data and not rely on
>user supplied memory to maintain it=A9=F6s internal data structures.
>In the example above, the put succeeds, user frees the memory, so its
>Pointing to garbage and a later a call to _get can't find the entry
>because the keys mismatch, i.e., a user supplied valid string key and
>NULL memory that the xhash node points to.
>Any ideas if there was a particular reason this was designed this way? I
>imagine, in most of the cases the key is inside the object being stored
>so it works out. However, as you can see, the xhash implementation
>can¹t be fully exploited/used.
>It would be trivial, I would imagine, to make a copy of the key and
>store that instead of just the pointer to user supplied memory. On
>removal in zap_internal, the memory would be freed.
>Thoughts? Concerns? Let me know :)