Not fixed actually
100 is a magic number; it should be defined as a constant where explanation could be provided
here and later magic numbers
It was a useful explanation, I do not see a good reason to remove it.
Again comment reflects the change rather then adding the context to the code. It would make more sense to write why we setup this specific value prior to firing the tests (e.g., to ensure consistent output)
The comment again reflects the change, though it also provides the context. However, I am not sure if it needs to stay. This context could be moved to the git commit message, which could later be checked via blame by anyone who plans to change this part.
Generally good, but a few fixes later it's going to be much better
I guess we can call is a defensive programming.
The change improves observability, which is always nice to see. I don't see any issues with it, so it's getting merged ASAP.
It doesn't make sense to do it this way. Condition is still duplicated.
Again comment style issue. Also I do not see a point in this scope
Condition above if (g_slist_length(a) != g_slist_length(b)) { should normally prevent this scenario. It would be strange if one list is going to finish earlier than another one.
Really nice change overall. I have some question marks in certain places + wording of commit message ( (INT_MIN = -2147483648 needs 12 bytes including NUL) (instead of NULL-terminator) slightly confused me. Nonetheless, great job. Just fix the minor issues that were pointed out and it's ready to merge.