I don't agree. There's a fundamental trick to avoiding signal 11. Don't use memory you don't have. It's really just that simple.

As for making memory consistent across different processes, there's two ways.
1) Always map the memory in the same place. You can accomplish it with mmap's MAP_FIXED flag, or shmat's shmaddr parameter. This means a little advance planning to avoid busy areas, but can work reasonably well.

2) Don't use pointers. Make the list a big table and use array indexes. Voila, your code no longer cares what area of memory your list gets put in.

Code:

#define LIST_END        (~(0UL))

typedef struct node
{
        unsigned long int next;
        unsigned long int prev;
        struct
        {
                char foo[64];
                int bar;
                double baz;
        } payload;
} node;

#define HEAD (shared_list[0])
...

node *shared_list=mmap(NULL, getpagesize()*16, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
HEAD.next=LIST_END;
HEAD.prev=LIST_END;

Of course it'll need to be mutexed somehow, or used with atomic operations etc. I've seen a working implementation of memory sharing across separate computers accomplished by setting up a special memory area that always exists in the same place, overloading the new operator, copying back and forth with RPC-like network calls, and mutexing properly. And these objects were real C++ objects with virtual members! A linked list is trivial in comparison. You should really read their manual pages sometime. shmat() can be induced to put things where you ask it to, not where it pleases. What makes you think it uses kernel memory? The compile time limit isn't fixed. Just echo a bigger value into /proc/sys/kernel/shmmax to raise it at runtime.

You can also map entire files and parts of files into memory with mmap, allowing a list even larger than physical memory to be used. This is often how large database implementations access their files. (as well as how nearly all program code is loaded.)