From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Kastrup Subject: Re: [PATCH v7 03/11] trailer: read and process config information Date: Fri, 07 Mar 2014 22:59:54 +0100 Message-ID: <87ob1hbrfp.fsf@fencepost.gnu.org> References: <20140306221409.29648.10706.chriscool@tuxfamily.org> Mime-Version: 1.0 Content-Type: text/plain Cc: Christian Couder , git@vger.kernel.org, Johan Herland , Josh Triplett , Thomas Rast , Michael Haggerty , Dan Carpenter , Greg Kroah-Hartman , Jeff King , Eric Sunshine , Ramsay Jones To: Junio C Hamano X-From: git-owner@vger.kernel.org Fri Mar 07 23:00:11 2014 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WM2oK-0004Y1-Et for gcvg-git-2@plane.gmane.org; Fri, 07 Mar 2014 23:00:08 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753232AbaCGWAB (ORCPT ); Fri, 7 Mar 2014 17:00:01 -0500 Received: from fencepost.gnu.org ([208.118.235.10]:48402 "EHLO fencepost.gnu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752866AbaCGWAA (ORCPT ); Fri, 7 Mar 2014 17:00:00 -0500 Received: from localhost ([127.0.0.1]:47433 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WM2o6-0006NS-MP; Fri, 07 Mar 2014 16:59:54 -0500 Received: by lola (Postfix, from userid 1000) id 2A013DF3F3; Fri, 7 Mar 2014 22:59:54 +0100 (CET) In-Reply-To: (Junio C. Hamano's message of "Fri, 07 Mar 2014 13:24:32 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Junio C Hamano writes: > Christian Couder 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