On Mon, 23 Sep 2013, Phil Dibowitz wrote:
>>>> + char *xml_buffer = new char[xml_buffer_len];
>>>> + uint16_t checksum = mh_get_checksum(in, size);
>>>> + int xml_len = snprintf(xml_buffer, xml_buffer_len, mh_config_header,
>>>> + size, size - 6, checksum, ri.skin);
>>>> + if (xml_len >= xml_buffer_len) {
>>>> + debug("Error, XML buffer length exceeded");
>>>> + return LC_ERROR;
>>>> + }
>>>> + struct zip_source *xml = zip_source_buffer(zip, xml_buffer, xml_len,
>>>> 0);
>>>
>>> why not use freep and let it free this on it's own?
>>
>> What's freep?
>
> freep is the last arg to zip_source_buffer(). From the man page:
>
> If freep is non-zero, the buffer will be freed when it is no longer needed.
Okay, I finally looked at the code and understand what freep is doing. :)
freep is for freeing the void* that is passed into zip_source_buffer(),
not the zip_source itself (as I was originally thinking). So, it would
not have worked in this case as I was allocating memory with new (vs
malloc).
Bottom line is, v5 patch is okay as-is.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
concordance-devel mailing list
concordance-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/concordance-devel
