Wireshark · Ethereal-dev: Re: [ethereal-dev] Ethereal memory leakage fix and feature enhancement

[Guy Harris <gharris@xxxxxxxxxxxx>]

> > Many, quite possibly most, such sequences would work much better if,
> > say, a GList cached the index of, and pointer to, the last element
> > fetched with such a "g_list_xxx()" call, and, if the index in the next
> > call was greater than or equal to the index of the last element fetched,
> > started the scan at that element.  (It would, of course, flush the cache
> > as necessary if the list changes.)
> > 
> > A GtkCList, as I remember, does those sorts of sequences.
> 
> Don't known. But this may be interesting.

Unfortunately, the GList API isn't all that well-suited for this - it
uses the same data type for a GList and for an entry in a GList, so
there's no way to keep that extra info in the list but not in every
element of the list.

In fact, it appears that a pointer to the list is just a pointer to its
first element, so adding a new element at the front of the list, or
removing an entry from the front of the list, actually changes the
"pointer to the list", so having a data type for a list entry that looks
like the first two elements of a GList, and casting the "GListentry"
pointer to a given element of the list to a "GList pointer", and hoping
code that gets a pointer to a list element never does anything that
would break if the extra cache weren't there, doesn't look as if it'll
work.

I'll see if there are any other ways to have GTK+ avoid looking for the
Nth element of the list when that's possible.