it's not described in list.h nor the readme

I’m looking at packaging this library in Fedora Linux. I see that some work has already been done to make it suitable for Debian.

Since the name of the library (list) is extremely generic, would you consider any of the following adjustments to the Makefile?

• Install the header as $(PREFIX)/include/clibs/list.h instead of $(PREFIX)/include/list.h. Dependent packages could either #include <clibs/list.h>, or compile with -I/usr/include/clibs.
• Rename liblist.so to something like libclibs_list.so.
• Rename liblist.a to something like libclibs_list.a.

If so, I’m happy to provide the necessary PR.

We're using this code and want to package our software (deb + rpm).

I'm not sure if we can (should) simply copy your code into our (MIT-Licensed) repo and be done with it, or if we have to get this code here packaged as a deb and rpm, too.

The latter is probably cleaner, but I'm not sure, if there are plans to build packages from the maintainer of list.

Any ideas?

@visionmedia,

I am a CS student right now at BMCC. In my data structures class we are writing a circular doubly linked list. The class is C++ but I'm trying to write it in pure ANSI-C. When I told my friend (@jwerle) about the project, he said I HAD to come check out your C repos. I'm so glad I did, your stuff is amazing! Thank you for releasing it here.

I just have a quick question (well, more than one actually) about the list_destroy() function. Why do you free(cure->val) before LIST_FREE(curr)? Does LIST_FREE(curr) not free it's associated value as well?

Thanks again for releasing the C code, I'm looking forward to working through some of your other C projects. hash looks particularly fun. :-)

Hi There,

could you release the 0.4.0 (or 0.4.1 with PR #43 included) on github?
The packaging scripts for Debian and RPM like to make use of these
releases to access the sources.

Best,
Marcus.

I came across this really interesting article in my reader a while back and just got around to clearing it out of my Safari reading list:

http://coryg89.github.io/technical/2013/12/12/the-tortoise-and-the-hare-loops-in-linked-lists/

I thought the function might be a good candidate for inclusion in this library. If you agree, let me know and I'll create a pull request with the new function and a test for it.

Compiling with GYP produces an obnoxious warning:

  CC(target) Release/obj.target/list/deps/list/list.o
../deps/list/list.c:173:13: warning: comparison of integers of different signs: 'int' and 'unsigned int'
      [-Wsign-compare]
  if (index < self->len) {
      ~~~~~ ^ ~~~~~~~~~

Thoughts on changing list_at to take an unsigned int?

Hello,

First of all I would like to say thank you for your library that is helpful a lot. I have a question/proposal - would you tell if it is worth adding a LIST_CONFIG_H, something like that:

// ...
#ifdef LIST_CONFIG_H
#include LIST_CONFIG_H
#endif

#ifndef LIST_MALLOC
#define LIST_MALLOC malloc
#endif

#ifndef LIST_FREE
#define LIST_FREE free
#endif
// ...

That way we will be able to redefine required macros like LIST_MALLOC or LIST_FREE without dozen warnings:

<command-line>: warning: implicit declaration of function 'sys_free' [-Wimplicit-function-declaration]
list/src/list.c:40:5: note: in expansion of macro 'LIST_FREE'
   40 |     LIST_FREE(curr);
      |     ^~~~~~~~~
list/src/list_iterator.c: In function 'list_iterator_new_from_node':
<command-line>: warning: implicit declaration of function 'sys_malloc'; did you mean 'malloc'? [-Wimplicit-function-declaration]
list/src/list_iterator.c:31:16: note: in expansion of macro 'LIST_MALLOC'
   31 |   if (!(self = LIST_MALLOC(sizeof(list_iterator_t))))
      |                ^~~~~~~~~~~
list/src/list_iterator.c:31:14: warning: assignment to 'list_iterator_t *' {aka 'struct <anonymous> *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
   31 |   if (!(self = LIST_MALLOC(sizeof(list_iterator_t))))
      |              ^
list/src/list_iterator.c: In function 'list_iterator_destroy':
<command-line>: warning: implicit declaration of function 'sys_free' [-Wimplicit-function-declaration]
list/src/list_iterator.c:60:3: note: in expansion of macro 'LIST_FREE'
   60 |   LIST_FREE(self);
      |   ^~~~~~~~~

If that seems reasonable to you, I'll be able to elaborate on a PR for that change.

Thank you.

Despite the last commit being 3 years ago, I still want to point out an error I found:

This is the original function to remove a node:

void
list_remove(list_t *self, list_node_t *node) {
node->prev
? (node->prev->next = node->next)
: (self->head = node->next);
node->next
? (node->next->prev = node->prev)
: (self->tail = node->prev);
if (self->free) self->free(node);
LIST_FREE(node);
--self->len;
}

But it should be:

if (self->free) self->free(node->val);

You did that correctly for the list_destroy function and that is probably why the error did not appear for you.

Because if I use list_remove(list, list_find(list, item)) it will break because list_find could return NULL

Thoughts on list_t->free defaulting to free from stdlib? I often forget to set it and end up having to chase memory leaks.

for the iterator, when malloc a ptr to iterator, we should use (list_iterator_t **ptr)to destroy, because
void
list_iterator_destroy(list_iterator_t *self) {
LIST_FREE(self);
self = NULL;
}

this is not save, because the
if (val == node->val) {
list_iterator_destroy(it);
return node;
}
it still ptr the memory of free

we should use list_iterator_destory(&it);

Hey TJ,

Sorry to bother you again, but there's something else I'm having trouble wrapping my head around. It's one question in two parts actually.

In the list_t struct{} in list.h you declare the function pointer members void (*free)(void *val); and int (*match)(void *a, void *b);. Then in list.c in the list_t *list_new() function you initialize them both to NULL.

Question 1:
I understand that free() is declared in the included stdlib header <stdlib.h>. So I assume that somehow the compiler links the function pointer to this stdlib function. Is that correct? If so, where does match() come from? I've looked through different online stdlib references and can't find a declaration for match() anywhere.

Question 2:
The information I've read so far about function pointers explains how to declare a function and a pointer and then assign the address of that function to the pointer:

int my_func(int, int) {do something with the ints};
void (*my_func_ptr)(int, int) = NULL;
my_func_ptr = &myfunc;

I don't see this happening for either function pointer in the list_t struct{}. You call both functions in the destroy(), remove() and find() functions but it seems like they're never initialized to anything other then NULL. How the heck do this work!? :-)

I know this is a long one, if you'd rather just point me to a link I'm totally OK with that. Teach a man to fish, right?

Thanks again.

Hi There,

a debian package that I maintain depends on on list.

Is there a good reason that you don't compile into a shared library, but just into a static one?

#include <stdlib.h>
#include "list.h"


int main(){
  list_t *gc = list_new();
  list_node_t *node =  list_append(gc, list_node_new("foo"));
  list_node_t *node_2 =  list_append(gc, list_node_new("bar"));
  printf("node: %s, node_2: %s\n", (char*)node->val, (char*)node_2->val);
  list_remove(gc, node);
  printf("length: %d\n", gc->len);
  printf("node: %s, node_2: %s\n", (char*)node->val, (char*)node_2->val);
  
  return 0;
}

Output:

node: foo, node_2: bar
length: 1
node: foo, node_2: bar

Is this a bug, or it's some compiler caching?