xserver: Cleaning up memory allocation functions and macros

[Daniel Stone]

On Mon, Apr 30, 2007 at 09:53:34PM +0200, Egbert Eich wrote:
> 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?

Given that it's now the basis for a couple of proprietary
implementations and numerous hacked semi-embedded systems, I'm going to
go with 'no, we have not'.

> 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.

How so?  You're making some odd leaps here.  From 'we mandate POSIX and
ANSI C with some extensions' to 'we don't care about anyone who we don't
currently support' is a long way.

> 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.

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.

> Maybe the issue will be moot and there is no non-POSIX compliant 
> system around any more. Who knows?

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.

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

None of us are standing in the way of actual portability.  So far,
no-one has raised any objections to anything that has been carefully
introduced which is actually far more of a barrier: if your system can't
reliably malloc(), what are the odds it supports variadic macros, or
autotools?

I have no issue with having our codebase remain as portable as possible.
As much as it may grate, I'm not suggesting we change the SI situation,
particularly as regards proprietary vendors who customise the SI and
never contribute the code back.

I'm equally comfortable demanding a working system as a baseline.
Currently, we demand a working compiler and toolchain, and don't attempt
to hack around it being broken.  Likewise, I see no need to compensate
for the failurs of malloc().  LD_PRELOAD hacks exist to replace it, but
I don't see it as our problem to deal with memory allocation.

Does anyone know of a case where this has even been taken advantage of
lately?  As I said, if malloc() is broken, there's not much point fixing
just the X server when all the apps -- which don't wrap malloc -- will
be dog slow anyway.

Put it this way: no-one is suggesting we impose onerous requirements on
any new ports, or actively break existing ports.

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

Not necessarily.  On all systems we know of that we build on today,
Xlib's XFree() could be replaced with free(), assuming that we used
malloc()/calloc()/et al everywhere internally.

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

Such as?

There are numerous documented ways to deal with this (e.g. LD_PRELOAD).
Why are we the only project that feels the need to wrap memory
allocation, based on a use case no-one can even think of?

> 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.

Maybe you could help us here by more clearly elaborating the 'pain'
case.

Cheers,
Daniel

[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 .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20070501/4a6f65f6/attachment.pgp>