Re: crap, i think LKD3 explains linked list head nodes incorrectly ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 20 Nov 2010, Dave Hylands wrote:

> Hi Robert,
>
> On Sat, Nov 20, 2010 at 10:09 PM, Robert P. J. Day
> <rpjday@xxxxxxxxxxxxxx> wrote:
> ...snip...
> >  that also suggests that a passage on p. 91 of LKD3 is inaccurate,
> > where it claims that "because the lists are circular, you can
> > generally pass any element for head."  but that can't be right, since
> > you must *always* keep track of the head node for any list, to avoid
> > processing it normally.  if you simply drop someone into the middle of
> > a circular, doubly-linked kernel list, there is no way that i can see
> > to know which node in that list is the head node when you run across
> > it during iteration.
> >
> >  does this make sense?
>
> I concur.
>
> And this is why routines like list_is_last need to be passed in the
> node to test along with the head of the list.

  huh ... i never knew that test routine even existed:


static inline int list_is_last(const struct list_head *list,
                                const struct list_head *head)
{
        return list->next == head;
}


  it of course just reinforces what i wrote -- that you better not
ever lose track of which node in a list is the "head" because there's
no way to ever recover it.

  i'm wondering, though, how useful a test of "list_is_last()" really
is.  normally, if you want to iterate through a list, you'll use the
standard "list_for_each()" or "list_for_each_entry()" constructs,
which will handle all the iteration for you.  and you'll stop at the
end of the list nodes without processing the "head" node, anyway.

  so why would you test for "list_is_last"?  if there's something you
need to do upon reaching the "last" node, why wouldn't you just do
that upon exiting the iteration loop?  i'm sure there are legitimate
uses for that test; i'm just wondering how many uses of that test can
be rewritten to not have to do that test and just do the corresponding
processing after exiting the iteration loop.

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux