xserver: Cleaning up memory allocation functions and macros

[Egbert Eich]

Daniel Stone writes:

 > > Are you suggesting to call the system provided malloc() from the code
 > > directly?
 > 
 > Is there a reason not to?  It's portable and generally highly optimised.

See below.

 > 
 > > X.Org has always also been the sample implementation of the X Window
 > > System. Therefore the goal has been to make it portable enough that
 > > it can be ported to whatever OS there is (*).
 > > Have we abandoned this goal? - To ensure the maximum portability 
 > > either macros or wrappers seem to be advisable.
 > 
 > malloc() is portable.  Attempting to write our own is suicide.  What
 > you're proposing is that we write our own C library, because some C
 > libraries out there somewhere aren't very good.  Even leaving aside the
 > fact that we don't even have enough developer resources currently to
 > just deal with the server, libraries, and clients, we are never going to
 > match glibc or Sun's libc.

Where have I suggested  that *we* write/maintain our own 
malloc? I've just suggested to leave a door open for those 
who want to port X to environments with different
needs and requirementes and make it possible to do so.
 
I don't even care to see that code - I just want to make 
this possible.

 > 
 > When we tried with the loader ('not all platforms have libdl, so let's
 > write our own'), we ended up exacerbating the problem.  To help LynxOS
 > or Amoeba or something, meant that we were unable to function on
 > Linux/IA64, Linux/HPPA, Linux/SH, and a great many other ports, because,
 > surprisingly, no-one wanted to write an entire ELF loader for their
 > particular platform, inside the X server.

Daniel, you keep flaming me for suggesting that *we* 
develop/support/maintain such kludges. 
Nowhere have I suggested this. - Do you think we can we 
agree here? :)
What I have suggested was to keep lightweight 'interfaces'
to accomodate those, who need to provide such kludges for 
their platforms. 
And we may want to stronly encourage them to *not* dump them 
into our code but to keep them nicely separated in a library 
which they will maintain for their platform and link against.

 > 
 > The use of malloc() is _not_ a portability problem.  If your platform
 > has a slow malloc(), then that is exactly the problem: _your platform_
 > has a slow malloc().
 > 
 > If the X server exhibits particular pathological behaviours, then we can
 > and should fix it.  But if your platform has particular endemic
 > problems, then I can tell you exactly where the fault and responsibility
 > lies.
 > 
 > I don't think you'll find anyone here opposed to actual portability.
 > We've always been quite careful to restrict the subset of the C language
 > and particular functions we use, and generally ask to make sure that any
 > new usage won't break various ports.

OK, portability is fine but it's different. I was suggesting to allow
for the possibility for other X Window System implementors to provide 
such 'workarounds' for problems that are known to exist *without* ever 
getting involved in supporting them ourselves.

What's so bad about using xalloc() and friends macros which have the 
exact same semantics as malloc() and friends instead of calling malloc()
directly? It's light weight, they will not add any overhead to the 
binary  produced, the semantics will be the same etc.

'Fix your platform' is not an option everywhere. On many platforms 
such errands get stonewalled by proprietray vendors. Sound technical 
reasoning or waving the POSIX flag will not make vendors to move - 
truckloads of money may. 
There are plenty of examples in open source applications where cludges 
have to be used to work around such issues to make them feasable on a 
wide range of platforms.

I think we ought to destinguish if we wanted to make these cludges ourselves
or if made it possible for others to make such kludges.

Do we care about these platforms? Most of *us* here on this list probably
don't. Still in an X.Org context we may want to: After all the X.Org
code is the SI  anyone can grab to implement the X Window System on
his pet environment.
Wrapper macros for the alloc functions seem to be a sufficiently lightweight
compromise to keep a bridge open to those who are in a different less
fortunate situation without making any commitment to ever get involved
in doing other people's homework - especially if the bridge is already 
there.

 > 
 > >  >   - free() can take NULL as argument, so it's not needed to test for NULL 
 > >  > before calling it.
 > > 
 > > Maybe not on all implementations? If we use a wrapper or macro this
 > > can be handled there. The default wrapper doesn't need to address this.
 > 
 > Check what POSIX/SuS says.  If it can take it, then we're fine.
 > 
 > > But they may be handy in situations where a failure is unlikely (so we 
 > > don't want to be bothered with special handling) but if it happens need 
 > > to be handled with a proper error message.
 > > Driver initialization is a situation that comes to my mind here.
 > 
 > Using xnf* _is_ special handling.

Right. But it's not done everywhere where these calls take place to
avoid having to add special treatment for the unlikely case in 
situations where a failure with a meaningful error message will 
just do.

Cheers,
	Egbert.