glib dependency for the X Server

[Carsten Haitzler (The Rasterman)]

On Sun, 2 Apr 2006 20:14:59 -0500 Adam Jackson <ajax at nwnk.net> babbled:

> On Sunday 02 April 2006 19:42, Eric Anholt wrote:
> > Talking individually with people, I've had a good response to this (and
> > it wasn't originally my idea, anyway).  I'm posting this here to make it
> > not be a shock when it happens, and give an opportunity for showstopper
> > issues with this plan to be brought up.
> 
> As brought up on IRC, and just recording it here for posterity, glib really 
> isn't an option as long as it abort()s on malloc failure.

agreed. if glib didnt abort() it'd be a worthwhile consideration.

if you want linked lists that are solid, well tested and without silly bugs
PLEASE recycle the attached code (you are free not to - but this will save you
time & effort - i striped out just the linked list handling code for you and
renamed it to "xd" (for x data)).

you are free to re-license it as you see fit and just put it into x's code (and
rename the functions and datatypes as you please). this is the list code I have
used in evas/e/edje etc. for years now and it's been tested to hell and back.
also it works ALMOST identically to glib's glist's (with the advantage that
appends are O(1), and no abort() on malloc failues (there is a call to check
if there was a failure)).

you are free to not use it - of course, but this would mean you get solid
linked lists, and dont need to worry about glib and its abort().

> Fundamentally I really like the idea of removing our half-baked portable 
> runtime layer and picking someone else's that works.  Let's not solve 
> problems twice.

it is a good idea - but finding one that is "right" can be hard. one that is
easy to use, solid, fast and not "stupid" is a hit & miss affair.

> - ajax
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)