2011/5/2 <[email protected]>: > On Mon, May 02, 2011 at 02:12:39AM +0400, Max wrote: >> it costs one additional pointer per each memory chunk allocated. > > Actually why dtor member is inside emem_chunk_t struct? and not inside > emem_header_t? :>
Because there are two modes the memory pool can work with. One that uses emem_alloc_glib() - it allocates one emem_chunk_t each time you call *e_allloc(). It uses emem_header_t only to chain these chunks for deallocation. Thus for each allocation we need a space to store the pointer to the destructor. That is why I choosed the emem_chunk_t - it is the most obvious. The second mode that uses emem_alloc_chunk() allocates big chunks on per demand basis and then breaks this chunk into small allocations. But destructor in this case can be called (or not) for every allocation. So the space (if needed) to store the destructor pointer is allocated within each allocation in very similar way like the canaries do. In that case I use pointer in emem_chunk_t to refer the last destructor in chain. > >> I would gladly read you comments, critics and suggestions regarding this >> patch. > > It seems that you put dtor data before canary, and you execute dtors before > checking one. > Buffer overflows can lead to executing code from given pointer. Frankly speaking, I don't know how canaries work but suppose you are right. I can change the order if you are sure that order matters. > About API I'd prefer smth like: se_register_gc_dtor(void *ptr, emem_dtor_cb > dtor) > which would register already allocated ptr. > > (+) It'd work with any se_* allocated memory. > (+) you can register it any time (not only at allocation) > (-) you should check if ptr is valid pointer (se_verify_pointer()) Can you provide a usecase for such an API? Are you sure that you really often decide during runtime whether you need destructor or not? :))) -- Max ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
