>Question 1:  In the quoted example, record data seems to be stored
>progressively in a block of memory as follows:
..
> If the memory block required for the list has to be 
>relocated when n grows, then I would expect the early addresses
>to become out of date, judging from the order in which this
>information is stored in the example.  But, since Tedd's algorithm
>works, my fear is evidently unfounded. Could someone please explain
>how the address information keeps up to date with memory relocation?

I haven't seen Tedd's example, so I can't comment on how he does it.

However, there is no reason all of the elements in a linked list have to 
be stored together. Since each one contains a pointer to the next, you 
can have linked list records scattered all over memory. As long as you 
have the address of the first record, you can "walk the list" from 
beginning to end at any time.

So when you run out of space in the first block, it's okay to leave it 
alone, create a new, separate block, and start allocating records in that.

>Question 2:  While "Tedd's Linked List" demonstrates how to construct 
>a Linked List, I would appreciate a simple example of a
>situation where a Linked List is of particular value.

The MacOS uses a linked list to keep track of the windows on the desktop. 
A linked list works perfectly, because windows always work in 
front-to-back order, and can be created or deleted at any time.

The function FN FRONTWINDOW gives you the address of the frontmost 
window's record. Each window's record contains the address of the window 
record behind it.

The MacOS uses linked lists extensively. Besides window lists, control 
lists, driver queues, event queues, and other internal OS structures are 
based on the linked list.

-Mars