xserver: Cleaning up memory allocation functions and macros

Egbert Eich eich at suse.de
Mon May 7 12:33:19 PDT 2007

Daniel Stone writes:
 > What would we be deprecating? Some macros and wrappers? Usually we
 > reserve deprecation notices for subsystems or large bodies of code;
 > else, we'd be issuing deprecation notices and attempting to consult with
 > a community that, in all likelihood, does not exist[0], every time ajax
 > committed something.
 > We have been explicit in aying many times since 6.7.0 that a system
 > which at least pays lip service to POSIX, as well as a compiler that
 > supports ANSI C (and, now, named initialisers and variadic macros) is
 > essential.
 > > Surely apart from the porting issues there may be plenty of other use
 > > cases where someone might want to wrap these functions. 
 > Such as?

I've hooked in various memory debuggers as well as small and quickly 
written wrappers that addressed exactly what I was looking for in 
the particular situation. 
It's easy, quick and it'll work everywhere - as it doesn't depend 
on LD_PRELOAD and other dynamic linker features. 
But I concede: On all systems I've got here (even the oldest ones)
are able to wrap or intercept malloc() and friends or any other 
system library call and there are different ways to do it.

I don't know of all other OS we presently support can handle this
similarly. At least noone has complained here so I assume they 
In this case we can probably savely drop all these wrappers.

 > [0]: I must admit to being at a loss over how to interact on matters
 >      such as these with people who aren't on xorg at .

I  understand that for some who work off the SI the 
traffic on xorg@ is to high wile most subjects are 
irrelevant to them.
Once we had the architecture WG and mailing list to 
discuss such things.
There didn't seem to be an overly large interest in 
that - also not from those who consume X.

We know some vendors who make use of our SI as they
are sponsors of this organization. So they could be
asked how they prefer to interact.


More information about the xorg mailing list