Hi Junio, Junio C Hamano writes: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: >> + * >> + * Usage example: >> + * >> + * struct commit_list *list; >> + * struct commit_list **next = &list; >> + * >> + * next = commit_list_append(c1, next); >> + * next = commit_list_append(c2, next); >> + * *next = NULL; >> + * assert(commit_list_count(list) == 2); >> + * return list; >> + * >> + * Don't forget to NULL-terminate! > > I am still not convinced that making it the caller's responsibility to > NULL-terminate the list after it finishes to append is a good trade-off > between run-time performance and ease of API use. If you are appending > thousands of commits to a commit list in a tight loop, surely you would > save the same thousands of assignment of NULL to the next field of the > element at the tail of the list, which may reduce the instruction count a > tiny bit, but that field was assigned in the last round in that tight loop > and the cacheline would likely to be owned by the CPU already, so it might > not make much practical difference. Ah, I hadn't thought about it this deeply. Changed now- thanks for the explanation. -- Ram -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html