Re: glib: g_get_any_init() bug fix

[Jeff Garzik <jgarzik pobox com>]

On Thu, 21 Jan 1999, Elliot Lee wrote:
> On Thu, 21 Jan 1999, Sebastian Wilhelmi wrote:
> > In different libs (like gtk+, gnome-libs, etc.) there are quite many
> > uses of getpwuid, getpwnam, etc. If they (or more accurate their _r
> > counterparts) all behave in the same unportable way, we might be
> > better of, including some thread safe g_getpwuid() functions into
> > glib. But I know, that this will make the Win32 porters unhappy and
> > the beholders of the feature freeze.... but that comes to my TODO for
> > glib 1.3.

> This is getting insane. We're going to wind up wrapping every single libc
> function in glib, turning it into a bloated piece of crap that nobody
> wants to maintain thing. Having a few compatibility aids is a necessary
> evil, but don't forget what glib was originally intended to do - provide
> data structure & utility routines for the most common tasks of C
> programmers. It succeeds at that task, but now everyone has their pet
> feature that "everyone needs". :)

Is the 'insane' part the paragraph you quoted, or something you omitted?

If gtk+, gnome-libs, and friends all implement the same get*() calls,
and have to deal with the same portability nightmares, it makes sense to
put those portability checks into a common location. 


> If someone is itching to write a new data structure for glib, adding GTrie
> might be neat... Or finding out why g_get_any_init() allocates 4K of
> memory. Or finding a way to speed up GMemChunk in the G_ALLOC_AND_FREE
> case so it is at least as fast as malloc. Or providing a way for apps to
> provide a hint as to the typical maximum number of {GList,GSList,GNode}
> items used, so that the memory pool sizes can be optimized. Or...

Any ideas on how to generalize Trie bucket distribution and size
decisions?

While we're on the subject of wish lists, here's mine in no particular
order:

* alloca implementation and convenience macros

* have 'make check' tests for each module, and (if possible) each
function in each module.  Not possible in all cases, but we should at
least try to have all functions covered, at least minimally, in the
tests. 

* new modules for: trie, skip list, rb tree, queue, stack, decent random
numbers (really a portability thing) 

* primitive leak detection for g_malloc/free

* benchmark GLib applications using a garbage-collecting malloc.  I
really think this will give most Gtk+ apps a good speed boost, even
though a lot of programmers distrust GC b/c they don't really understand
how GC works.  "Call malloc() without calling free()?  How the heck
could that ever work?"  :)

	Jeff