[Xcb] xcb/libxcb git commit 46413cd85

[Peter Harris]

Barton C Massey wrote:
> In message <475ED27B.7000701 at hummingbird.com> you wrote:
>> 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.
> 
> 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().

Linux and Solaris have LD_PRELOAD, which can avoid most of the problems,
but what if someone is using Hoard, Boehm, Electric Fence, or some other
alternate malloc library, where "free" is #defined away to some other
function? I suppose people could participate in even more #define
gymnastics to try to make the default free available as "libc_free" or
something.

> Splitting the interface imposes an extra software
> engineering burden...

Agreed. I understand if you don't want to add this. I have to admit,
it's mostly just Windows users that get bitten. I'll just be grateful
that I didn't waste any time writing a patch that won't be accepted.

> 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?

Each library is ANSI compliant on its own. The problems arise when you
start mixing and matching libraries.

What happens on Linux if you have library A statically linked against
uClibc, and library B dynamically linked against glibc? How does your
main program call the right "free" function for each, unless each
library exports a free for you to call into? Since uClibc is LGPL, I
suppose you can recompile. Okay, what if you s/uClibc/the proprietary
Hoard release/, and you can't recompile (assume you want to work with
your distribution's upstream XCB binaries, and a 3rd party binary-only
library)?

It's worse on Windows, where the malloc/free you get with a debug build
is incompatible with the regular malloc/free. This means that, if you
don't have xcb_free(), you have to rebuild the entire world (if you even
have source code for everything, which you might not) if you want to
debug anything. It's somewhat similar to the problems with mudflap,
except the calling conventions don't change, so you can successfully run
mixed binaries if you have and use per_library_free.

Thank you for your attention.

Peter Harris
-- 
     Hummingbird Connectivity - A Division of Open Text
Peter Harris                    http://connectivity.hummingbird.com
Research and Development        Phone: +1 905 762 6001
peter.harris at hummingbird.com    Toll Free: 1 877 359 4866