I don't like offsets because I don't they are that straightforward. First, the offset is useless without the base pointer. So that either needs to be global or you need to store that too (and now you have fat pointers). But the base can change, so you really need to store a reference to it. yuck.

And you still can't delete anything when using offsets. Forgetting about random deletions (which are important) an array works for a stack, but not a fifo, and fifos are at least as common.

It's not as if the design alternative you're suggesting --- ie, storing "struct-proc-star" all over the place --- is much safer. You still have to track down and invalidate every stale "struct-proc-star" when you delete from the list. And this notion of having to store a base pointer and the pointer --- you're storing the identity of the collection somewhere. I think this is a straw man.

If you have a collection where random deletion is central to the design, then by all means, use a list. The process table is perhaps one example.

But just because you might at some point need random deletion doesn't mean it's a win to use a linked list. The process table will constantly have random deletions, but pid 47481 is far more likely to die at any moment than pid 10. Do you know how not-expensive it is to memcpy 1-3 "struct procs"? How often is the process table indexed or traversed? Roughly every 10th scheduling quantum? Are you sure you're optimizing for the right thing?

Incidentally, if you need FIFO behavior, a ring buffer is a nice thing to have in your toolchest.