[PATCH 2/6] xserver: Possible memory leaks, stricter option checks, UnInit (NewInputDeviceRequest)

[Magnus Vigerlöf]

On Friday 30 March 2007 19:26, Alan Coopersmith wrote:
> Eirik Byrkjeflot Anonsen wrote:
> > Alan Coopersmith <alan.coopersmith at sun.com> writes:
[...]
> >> And ANSI C requires free(NULL) to be a safe no-op anyways, so it's not
> >> needed at all on modern OS'es.
> >
> > But I don't think xfree(NULL) is guaranteed to be safe.  And I doubt
> > that xfree(NULL) is specified as being "as safe as" free(NULL).
>
> We define xfree(), so what stops us from raising xfree(NULL) from
> "Undefined" to "Guaranteed safe no-op"?   All we have to do is document
> it - it won't break anything that works already.   (If you want to
> kill the process, call abort(), not Xfree(NULL) and hope it segfaults.)

I don't have any problem to start crawl through the code and start fixing 
these kinds of things. But shouldn't we address all the different naming 
schemes and implementation around malloc (et al) at the same time? For malloc 
I've found the following defines/functions so far in xserver: xalloc, 
xnfalloc, Xalloc, __glXMalloc, XtMalloc, and xf86confmalloc. Some are needed, 
but not all for sure... Eliminate all but xalloc, Xalloc, xnf*, and XNF*? 
Maybe even the ones starting with 'x' as well?

Is there a macro that set the freed pointer to NULL after freeing the memory 
somewhere? I'd prefer a clean SEGV instead of an obscure error that is caused 
by a stray pointer... And if that can be made in a simple manner in the code 
I'd be happy. XfreeZ(ptr) ?

Cheers
  Magnus V