Describe intrusive (embedded) linked lists in C, and typical usage pattern.

• A. The link pointers are inside the user’s own data structure; you embed a next field and cast; used in kernel data structures to avoid wrappers.
• B. The list node is separate and points to data.
• C. The list uses a double-link structure.
• D. You cannot cast between data and list node.

Answer: (A)

Intrusive (embedded) linked lists place the linkage inside the items themselves. The data structure you want to link includes the list pointers (for example, a next field, and possibly a prev field) as part of its own fields. When you insert, remove, or traverse, you treat that embedded pointer as the list node, and you recover the full containing object from the address of the embedded field using pointer arithmetic (often via a container_of-like helper). This means you don’t allocate separate wrapper nodes; the list node is embedded directly in each item, so removing or moving items does not require extra allocations and can improve cache locality. It also enables an item to participate in multiple lists by embedding different link fields with distinct names.

Typical usage pattern involves defining your data structure with an embedded list field, maintaining a list head separately, and using helper macros or functions to operate on the embedded node. To access the full data from a list node, you convert back to the containing structure (the container) from the address of the embedded link. This design is common in kernel and low-level systems code precisely because it avoids wrappers and keeps related data together, while still allowing flexible list management.

The other patterns describe using a separate, dedicated list node or assume only a single structure of list linkage, and they don’t capture the idea of embedding the linkage inside the payload. Also, you can recover the containing object from an embedded node, so you can cast between the link and the data via the container approach, not vice versa.