Wayne Davison wrote: >On Sat, 14 Sep 2002, Bill Bogstad wrote: >> [list.c] makes some effort to allow the upper end of the allocated >> range (list->high) to increase beyond that specified when the array >> was originally created, but an incomplete effort to support a >> reduction in the low end (list->low). > >Sorry I missed the original report of the bug in the LF_SPARSE case. >The incompleteness might be in the non-LF_SPARSE case, where we assume >that the list is always growing upwards (see below). > >> Also, I am not sure what the flag LF_SPARSE means. In general, lists >> appear to always be sparsely allocated. > >There are a few things that don't pass in the LF_SPARSE value, such as >the datasrc_list. In such cases, the first array element is always >allocated first, and growth must proceed in an upward direction one >element at a time. If the code skips around at all, it must use >LF_SPARSE. > >Here's my proposed change to fix the bug in list.c. See if you like it. I haven't looked at it closely, but I don't think it is sufficient. From my previous note: >I've run trn under gdb with breakpoints in listnum2listitem() and I >can say for a fact that under some circumstances when the list is >article_list that attemps are made to access indices below the >current list->low. Even with your changes, list->low is never updated whether LF_SPARSE is set or not. I suppose it's possible that this doesn't matter, but I'ld feel safer if we updated list->low when we accessed (added) nodes below that value. If you don't think this should be happening, then I can run trn under gdb again and try to figure out the cirumstances when I see this happening. I had assumed that the rest of trn's code was correct and the problem was in list.c... Bill Bogstad bogstad@pobox.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
