Possible GLib bugs & anomalies

["Damon Chaplin" <DAChaplin email msn com>]

Hi,

I'm currently trying to write some DocBook documentation for GLib.
I've found a few possible bugs and some functionality I'm not too sure
about...


g_array_set_size()
	if the new size is smaller than the current size, and zero_terminated
	is set, should it zero_terminate it?
	
GPtrArrays are weird!
	If you use g_ptr_array_remove/remove_index, the last element of the
	array is moved to the space which was occupied by the removed item.
	I think users will find this quite confusing. Arrays are generally
	considered to have a sequential order, so moving elements around
	is probably a bad idea.
	I think we should do what the Java Vector does - move the
	rest of the elements down one place.
	If you really want to keep the current, slightly faster, version,
	then I think it should be renamed to g_ptr_array_remove_fast
	or similar, and use the current name for a default, more intuitive,
	version.
	(Also, why are there no remove functions for GArray and GByteArray?)

All array free functions:
	All of the array free functions take a 2nd boolean argument which
	specifies if the space allocated for the actual array should be freed.
	Why? I think we should try to make these data structures as opaque
	as possible, and so this option should not be available. If you
	free an array, everything should be freed. Is there a good reason for
      freeing just the GArray structure?

GListAllocators:
	Can these actually be used?
	g_list_alloc() calls g_list_set_allocator(NULL) so it seems to me
	that you always end up using the default allocator anyway.
	Is this a bug?
	I think list allocators are too dangerous anyway. If you allocate
	or free list elements with the wrong allocator set (which is very
	easily done by forgetting to reset it), you could get into nasty
      memory problems.

Why is there no GStack or GQueue? (they could be created fairly easily using
GArray & GList).

Damon