incorporating lists in other parts of busybox

[Rob Landley]

On Saturday 17 June 2006 6:54 am, Robert P. J. Day wrote:
>   is there a concerted effort to use the general busybox list
> structures to support lists?

Concerted is a bit too strong of a word, but yes we're trying to move stuff 
over.

See the recent discussion on whether or not we need a doubly linked list type.  
I'm still strongly hoping we don't, but haven't entirely ruled it out yet.  I 
just haven't gotten back to it...

> for instance, in networking/interface.c, 
> we read:
>
> struct interface {
> 	struct interface *next, *prev;
> 	...
>
> should BB structures that have their own next and prev pointers be
> replaced with (simpler) structures that use the list structures
> instead?

If C had a facility for subclassing types, yes.

To get rid of the x86-64 warnings in lash.c (which I have a patch for, should 
get a chance to check it in today), I wound up having to do a double typecast 
which is just evil.  Pondering better solutions, but the fundamental problem 
is that our list structures just don't handle arbitrary data yet.

In theory, we could rewrite the list functions to handle _just_ the link 
pointers (which if they're the first element in the list, we should be good).  
Then figuring out what else is in the structure is the caller's problem.  
(This is another way of handling the "free the list and its' contents" 
issue.)

Lists of strings are common enough we'd need a helper function that did a 
list_strdup() style thing, vaguely like:

void *list_strdup(char *str, void *next)
{
  char *temp=xmalloc(strlen(str)+1+sizeof(void *));
  strcpy(temp+sizeof(void),str);
  *(void *)temp = next;

  return temp;
}

Although probably the caller should do the temp=next part rather than passing 
it in.

Figuring out what to do about this is one of my 1.3 items...

> rday

Rob
-- 
Never bet against the cheap plastic solution.