Re: list.c/what are its operating parameters?/is it broken?

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


On Tue, 24 Sep 2002, Bill Bogstad wrote:
> I'd consider that a breaking of the abstraction that the LIST type
> provides to the rest of trn's code.

If it's done with a call that basically says, "oops, my previously
specified low value was wrong, please change it" it's be OK.  I've been
hesitant to let the code change the value itself because nothing is
supposed to try to store a value lower than the low value that was
specified when the list was created.

So, the best solution for trn would be to fix it to never try to use a
value that is less than the "low" value.  One quick-and-dirty kludge
would be to modify the code that creates the article_list object to pass
in "0" instead of "absfirst", but hopefully a better solution will
present itself.

> Truthfully, I also can't follow the listnum2listitem() code well
> enough to be sure of the effects if the code actually tried to access
> something in the new range of items.

There will be no problem as long as the low value is decreased in a
multiple of the items_per_node value.  And we're only talking about the
LF_SPARSE code path -- any use of a non-sparse list that doesn't start
from the low value and create every item in order is not a supported
method of access.

> One concern, I have is that depending on access patterns; we could end
> up with two LISTNODES with overlaping ranges in the article_list.

That would be quite invalid.  The current code does not prevent weird
things from happening if you use it wrong, though, so it could be
improved to slap the caller around in certain circumstances.


This email is sponsored by:ThinkGeek
Welcome to geek heaven.

[Index of Archives]     [Photo]     [Yosemite]     [Epson Inkjet]     [Mhonarc]     [Nntpcache]

  Powered by Linux