[Xcb] xcb/libxcb git commit 46413cd85

[Barton C Massey]

In message <475ED27B.7000701 at hummingbird.com> you wrote:
> Eamon Walsh wrote:
> > +        <doc> * The returned value must be freed by the caller using free().</doc>
> 
> That should read xcb_free(), not free().
> 
> Oh. I see we don't have an xcb_free() function. That can be considered a
> bug. Some systems (*cough* Windows *cough*) frequently run into problems
> when a shared library is linked to a different libc (and therefore a
> different malloc/realloc/free) than the executable.
> 
> Xlib has XFree(). XCB needs its own free() for all the same reasons.
> 
> If you like, I can create a patch to add this function.
> 
> Peter Harris

While I understand what you're saying, I have to
respectfully disagree here.  Unlike with Xlib, we worked
hard in the API design of XCB to ensure that it always uses
system malloc(), and therefore can always use system free().
If someone's boxes are sufficiently borked that they can't
call free() on pointers created by malloc() calls in their
library, in my opinion we can't let this be XCB's problem.

Splitting the interface imposes an extra software
engineering burden of making sure that some distant routine
knows whether the data structure it is freeing came from XCB
or elsewhere---I am loathe to impose this burden, especially
since bugs of this type will rarely be exercised and
therefore casual mistakes will be made and propagated.  In
addition, splitting the interface encourages the design of
magic memory allocators and deallocators for XCB, which I am
also happy to discourage.

That said, I'm certainly willing to listen.  Other than
making XCB work in non-ANSI-compliant library environments,
what other problems might having an xcb_free() solve?

    Bart