[xcb] Memory management in XCB (was: XCB polling and single-threadedness)

[Carl Worth]

On Jul 6, Andy Howe wrote:
 > >Quick work!  BTW, how do I discard the event record returned
 > >by XCBWaitEvent()/XCBPollEvent()?   All the stuff in xcb.h
 > >writes the event record into user-supplied memory.
 > 
 > You just need to free() the event returned by
 > XCBWaitEvent()/XCBPollEvent(). As an example, Hypnomoire does this in
 > event_thread().

Lack of automatic memory management should be on everyones' list of
Top 10 Reasons to Hate to Love C.

In order to deal with the inherent ambiguity when a function returns a
pointer, (to free or not to free?), I've been leaning toward following
the following stylistic conventions in most of my code:

1) In general, avoid the ambiguity by returning data in storage passed
   into the function.

2) When returning a pointer is necessary, clearly indicate in the
   function name whether the function is allocating memory that must
   be freed, (eg. foo_alloc, FooAlloc, FooCreate, etc.).

3) Provide corresponding "free" functions to balance any functions
   that allocate memory, (eg. foo_free, FooFree, FooDestroy, etc.).

So, looking at the case in hand, I would vote for following (1) and
having XCBWaitEvent and XCBPollEvent fill in an XCBGenericEvent passed
in to the function. Of course, this is similar to what Xlib does.

I anticipate Bart may not agree with me, as this touches on an
interesting discussion about coding style that we started during
USENIX.

I glanced through xcb.h and the common case where functions return a
pointer there is with all the *Rep returns. My style tip (2) doesn't
help much as the protocol spec. already gives us names with Create,
Destroy, Alloc, and Free in them. I haven't really programmed in XCB
enough yet to make any recommendation on whether this part of the API
should change or not.

Oh, and in line with (3), it seems we're missing an XCBDisconnect to
balance out XCBConnect, no? valgrind tells me that test/main is still
holding onto 500+kB of memory that it could have freed before
terminating. (No truly leaked memory though which is good).

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725