On Mon, 2 Nov 2009, John Engelhart wrote:
> I'm wondering if the API could be expanded such that there were two calls:
> one that provided the length of the buffer needed to hold the expanded
> result, and one that did the expansion in to a user supplied buffer.
I'm not particularly against the idea, I'm just not too thrilled about the
idea of providing two new functions that don't offer a lot of news. Also, they
are highly specific for the ares_expand_*() functionality while one could
argue the way you do for all the functions c-ares provides that return
allocated data. And I don't want two new functions for each and every one of
them.
So where do we draw the line?
> The reason why this would be useful to me is because the way things are now,
> I get the result from ares_expand_() and use that malloc() buffer to create
> an Objective-C object. Typically that object will allocate its own buffer
> to store the string and make a copy. I then immediately free() the
> ares_expand_() buffer.
But that's your choice, you can just as well keep the data c-ares allocated
and then avoid the extra alloc+copy.
> I'd really like to just be able to allocate a buffer off the stack to hold
> the temporary expanded results. This also reduces the chance of a memory
> leak
It's not very hard to make sure that memory doesn't leak in such a design. I
find that a rather weak argument.
-- / daniel.haxx.seReceived on 2009-11-02