xserver: Cleaning up memory allocation functions and macros

[Egbert Eich]

Keith Packard writes:
 > One significant reason the current codebase uses wrappers is to provide
 > a place where broken semantics can be repaired. In days of yore, malloc
 > differed in several key ways across systems; wrapping all calls provided
 > a place where these differing implementations could be made the same.
 > With all of our supported systems now providing POSIX semantics, it may
 > well be that this particular reason is gone.

OK, you say 'supported systems'. That means systems that we support
ourselves as X.Org, right?
>From the old X.Org we inherited - together with a pile of money -
the burdeon of the SI. The SI was always valued as a resource from
which anyone could draw the foundation for his/her own X Window
System implementation.
a. Have we abandoned this notion?
b. If not, can we estimate how many of these consumers or
   potential consumers of this code still need to rely on this 
   feature? 
I mean we could say 'they are not here, so we don't care'. This 
would then implicitely be a 'yes' answer to question a.
If the answer is 'no' we ought to put more efforts behind finding
this out by making an official deprecation plan with announcements
and opportunities to comment.
Maybe the issue will be moot and there is no non-POSIX compliant 
system around any more. Who knows?

I know that this is a sh** issue for a lot of people here.

 > 
 > An issue with the current situation is that other standard library
 > functions cannot be used (strdup, etc) as they 'may' use a different
 > allocator, so our code must wrap things like that as well. The question
 > is how far we must go in replacing the underlying system so we can
 > retain the ability to replace the allocator.
 > 
 > When it was required to make the system work on our supported platforms,
 > it had value for us. Now that it provides only convenience for other
 > people, we must weigh our own inconvenience and additional development
 > burden against hypothetical benefits for other developers.
 > 

I agree. 
But has the evaluation of pain vs gain really been completed?

Do we have a list of system functions that return memory that later
needs to be freed? 
Do we have an estimate of the pain really involved?
How big would the gain be dropping these?

I expect we can only replace things in the server and need to keep 
macros or wrapper functions for the libs.

Surely apart from the porting issues there may be plenty of other use
cases where someone might want to wrap these functions. 

The point is: once these things are gone they are painful to reintroduce.
So we ought to look a little more closely at the gain/vs tradeoff before
we make a decision.

Something I don't argue is consolidating the insane amount of alloc/free
functions currently around to just a single one.

Cheers,
	Egbert.