@aktau klib doesn't have docs and the author doesn't seem to merge the PRs people send. Having a divergent fork is not a problem: it's is a necessity (`kl_empty` was implemented by me, for example). As I said in the commit message:

>   The whole point of abstract data structures is to avoid reimplementing
>   common actions. The emptiness test seems to be such an action.

@Hinidu

> remove size and save some memory if we will use these lists more actively

This makes querying for the length of the list an O(n) operation. Not an option. Specially if we're going to use these lists more actively and we will.

> rewrite kl_empty as return kl->size == 0

I will totally do it. My emptiness test was inspired by the iterator comparison. Testing size doesn't depend on the list type: can be a pure macro.

> create #define kl_size to access size (and maybe replace usages of kl_empty by kl_size == 0)

I think it's OK to use `list->size`, but `kl_empty` is still valid: `!kl_empty(list)` reads much better than `list->size != 0` or `list->size`.