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

Magnus Vigerlöf Magnus.Vigerlof at home.se
Fri Mar 30 13:49:49 PDT 2007

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

  Magnus V

More information about the xorg mailing list