On Thu, 21 May 2015, Alan Cronin (alcronin) wrote:

> For the first approach of creating a custom allocator have you heard of
> people taking this approach before to zero memory. In this case it would be
> tested using in house tools and up to the creators of the allocator to
> ensure that it works. My only concern with this approach is in the free
> callback that cURL uses to deallocate memory. All that is supplied is an
> address and not a size, so to zero the data before freeing would need either
> a modification of the callback or a structure to be created around the data
> which stores the size, which can lead to issues in itself.

What issues would that lead to? As long as the function you use to allocate
memory allocate memory on aligned addresses you should be fine on most
architectures I would think. I've not done a custom allocator for this
particular purpose but I've done similar operations many times in the past.

Such a custom allocator would need to store the size of the newly allocated
block so that it later can figure out how much to clear. Something like this
_untested_ pseudo code:

struct memory {
   size_t size;
};

void *malloc_replacement(size_t size)
{
   struct memory *mem = malloc(sizeof(struct memory) + size)
   if(mem) {
     mem->size = size;
     return mem+sizeof(struct memory);
   }
}

void free_replacement(void *ptr)
{
    struct memory *mem = ptr - sizeof(struct memory);
    memset(ptr, 0, mem->size); /* clear memory area */
    free(mem);
}

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html