Junio C Hamano <gits...@pobox.com> writes:
> Christian Couder <chrisc...@tuxfamily.org> writes:
>> This patch implements reading the configuration
>> to get trailer information, and then processing
>> it and storing it in a doubly linked list.
> "Read and process the ...", perhaps?
>> The config information is stored in the list
>> whose first item is pointed to by:
>> static struct trailer_item *first_conf_item;
> If feels somewhat strange if a doubly linked list has only the first
> pointer without the last pointer, unless the previous field of the
> first one by convention points at the last one, forming a cycle
> (which I think is a reasonable thing to do, as a desire for a quick
> access to the top and the bottom is often a reason to use doubly
> linked list---I didn't check if you implement it that way, though).
Can't say I agree here. Basically all my doubly-linked lists are not
for traversing data forwards and backwards but for making it possible to
delete list members that have not been reached by list traversal but
rather by orthogonal data access methods. Consequently, my back links
usually don't point to the previous list member (which would require
special-casing the first element) but rather to its referring
forward-pointing link (which for the first list element means a pointer
to the list head).
Having a "last" pointer is an orthogonal concept: you need it if you
want to append to a list's end without actually looking at its members.
The presence of such a last pointer actually makes it quite more ugly to
delete the last member of a doubly-linked list reached by some other
means as you then need to have some way of adjusting the tail pointer
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html