Re: GList and GSList data abstraction

[Kevin Lai <laik tnt stanford edu>]

I also agree that allowing an error like that is a bad idea. The other 
abstraction macros also allowed it, so I changed them in the included 
updated patch too.

Any thoughts on removing (or at least deprecating) redundant functions 
like g_list_nth_data(), g_list_free_1(), g_list_remove(), and 
g_list_delete_link()?

> It doesn't hurt to have the macro, but realistically you aren't
> gaining any benefit; so much code already uses ->data directly that
> it's impossible to ever change, and the abstraction is useless.
> 
> > +#define g_list_data(list)	((list) ? (((GList *)(list))->data) : NULL)
> >  
> 
> If list is NULL then it's an empty list with no elements, and code
> accessing the data in an empty list is broken - so probably you don't
> want to silently accept an off-by-one error like that.
> 
> I would say either make it a function with g_return_if_fail, or just
> let it segfault (NULL will always segfault in an easy-to-find way).
> 
> Havoc

Index: glib.h
===================================================================
RCS file: /cvs/gnome/glib/glib.h,v
retrieving revision 1.155
diff -u -r1.155 glib.h
--- glib.h	2000/03/01 09:44:09	1.155
+++ glib.h	2000/03/02 02:59:00
@@ -991,8 +991,9 @@
 		                 GCompareFunc    compare_func);
 gpointer g_list_nth_data	(GList		*list,
 				 guint		 n);
-#define g_list_previous(list)	((list) ? (((GList *)(list))->prev) : NULL)
-#define g_list_next(list)	((list) ? (((GList *)(list))->next) : NULL)
+#define g_list_previous(list)	(list)->prev
+#define g_list_next(list)	(list)->next
+#define g_list_data(list)	(list)->data
 
 
 /* Singly linked lists
@@ -1042,7 +1043,8 @@
 		                 GCompareFunc    compare_func);
 gpointer g_slist_nth_data	(GSList		*list,
 				 guint		 n);
-#define  g_slist_next(slist)	((slist) ? (((GSList *)(slist))->next) : NULL)
+#define  g_slist_next(slist)	(slist)->next
+#define  g_slist_data(slist)	(slist)->data
 
 
 /* Queues