Use of complete GList functionality? Change to GSList?

[Dave Peticolas]

Derek Atkins writes:
> Dave Peticolas <dave@krondo.com> writes:
> 
> > GLists are allocated with the glib memory routines. You cannot mix
> > them with the libc routines. Any engine structures that the RPC
> > backend creates needs to use glibc memory routines if they are used
> > for that in the engine. Is RPC going to be able to handle that?
> 
> Unfortunately no.  I can't plug in a special malloc into RPC.  Memory
> get's alloc'ed out of libc (which is where the general XDR routines
> live).  Oh well, I was hoping to avoid the double-copy. I'll just have
> to copy and fix everything on the other end.  At least I can still
> pass a GList _into_ the RPC engine (casting a GList to a GSList will
> "work" for read-only operations).  I just can't expect to get one out
> on the other end :)

Ok. As long as you are doing the copy, you might consider using the
engine API to build the 'real copy' rather than just copying the
structure itself. That would make the RPC backend much more robust
against implementation changes. For example, a lot of the strings in
the structures are really handled by the engine string cache, and
should't be directly malloc'd with either libc or glib routines.
Having the backend so dependent on the internal structure and
implementation of engine objects makes me very nervous.

Backend aside, there are probably several uses of GList in the
engine that could be converted to GSList without losing needed
functionality.

dave