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. ..wayne.. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
