>As one builds up the list and progressively increases the handle size, the 
>memory block contains successive entries like the following

>200000
>100
>1000
>200008
>101
>1001
>200016
>102
>1002
>.
>.
>.
>where 200000 and like numbers are addresses to the next record and
>100,1000 are two items stored in the first record, 101,1001 are
>corresponding items in the second record and so on. Tracking through
>Tedd's algorithm it seems to me that if, as the size of the list grows
>sufficiently that the memory block associated with gDataH& has to be
>relocated, then surely the addresses for the early records would become
>out of date.  

Actually, the real data would look more like;

8
100
1000

16
101
1001

24
102
1002
.
.

Then when you got the handle, let's say it contained "5432", you'd look 
at address "5432" for the pointer, which would be your 200000. That's 
your "base address"; all references into your list are offsets from this 
base.

So, you'd actually look at address 200008 for the second entry in the 
list, but the "address" stored in the list for that is the 8; the 200000 
comes from the location of the start of your list. If the Mac moves the 
list, the pointer gets changed as well, from 200000 to say 208000; as 
long as you use the handle and add the 8, you'll still find the second 
entry, but now at 208008 instead of 200008!

Bill