Re: [PATCH v7 03/11] trailer: read and process config information

From: David Kastrup <dak@gnu.org>
Date: Mar 7, 2014, 21:59 UTC
Message-ID: <87ob1hbrfp.fsf@fencepost.gnu.org>
In-Reply-To: <xmqqmwh1u2gf.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 19 quoted lines

> Christian Couder <chriscool@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 accordingly.

-- 
David Kastrup