In ringbuffer.c, and in exercise 44 of LCTHW, you have a couple instances similar to:

void *result = memcpy(buffer->buffer + buffer->end, data, length);
check(result != NULL, "Failed to write data into buffer.");

However, memcpy merely returns 'dest'. The return value is not indicative of success or failure in any way. Checking it against null is harmless but seems like a bug, and may mislead readers as to how memcpy works.

I was alerted to this issue in the comments section of a recent Hacker News post: https://news.ycombinator.com/item?id=8059283

https://github.com/zedshaw/liblcthw/blob/master/src/bstree.c#L192

I don't know if its meant to be missing the else. You should clarify by either using an else, or put the if on the next line.

https://github.com/zedshaw/liblcthw/blob/master/tests/list_algos_tests.c#L54

Here we are calling List_create, a function that until now has taken no args, on words, which is the list of words that we just destroyed.

Should this line be words = create_words();?

RingBuffer_write() checks for RingBuffer_available_space() but reports RingBuffer_available_data(). Also, the request/available order does not seem to be correct:

    check(length <= RingBuffer_available_space(buffer),
            "Not enough space: %d request, %d available",
            RingBuffer_available_data(buffer), length);

A ring buffer should write around the "edge" of the buffer. Zed's RingBuffer merely resets once it is empty.

Consider renaming to FancyBuffer or AdvancedBuffer, or change the implementation to write around the edge.

The Problem

Missing a test to check if the code actually worked or not.

My Approach

Learning from p. 149 "Question Authority". 😉
Using TDD (see attached image), where I first write the test-cases first I stumbled upon a bug in the lists_tests.c file.

The code will not really test if the list has been cleared and destroyed.
The test will PASS by just adding the following minimal implementation function to list.c

void *List_clear_destroy(List *list) {
  return (list);
}

Suggested Solution

I suggest adding a test using mu_assert(), to actually test the list variable.
Now I do not know if there is any better way to test this, but at least it is testing something. 😄

 char *test_destroy() 
 { 
     List_clear_destroy(list); 
     
     // Add the following test 
     mu_assert(list->count == 0, "Failed to clear list");

     return NULL; 
 } 

What do you think @zedshaw ?
Do you have a better way to test and check if the list is empty, please let me know because I am very curious about how that could be done.

When I try to compile the library under Ubuntu 17.04 I receive the following error messages:

build/liblcthw.a(darray_algos.o): In function `DArray_heapsort': liblcthw/src/lcthw/darray_algos.c:12: undefined reference to `heapsort' build/liblcthw.a(darray_algos.o): In function `DArray_mergesort': liblcthw/src/lcthw/darray_algos.c:18: undefined reference to `mergesort'

These errors appear to be related to the linker not finding heapsort and mergesort in available paths. Perhaps these sorting algorithms are not available by default.

I couldn't resist. I know that this is not the proper place. But I love you ❤️ .
I hug you 👐
I thank you for LCTHW I am into it, I'll finish it. then I'll try to do great things that will never matter because - fuck the planet - we're all gonna day anyway. But I'l do great things because a kind human like you exists and pushing us a step forward to a better humanity.

check(result != NULL, "Failed to write data into buffer.");

Hey, looks like something has changed in OSX but neither the examples from the book (starting w/ ex32) nor the code in the git repo will compile. Error below:

Undefined symbols for architecture x86_64:
"_List_merge", referenced from:
_List_merge_sort in liblcthw.a(list_algos.o)
(maybe you meant: _List_merge_sort)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [tests/list_algos_tests] Error 1