3 ms·
As proven by <sys/tree.h>, the same approach can still be used to generate functions, even external, shared functions as opposed to static routines duplicated i
by wahern 5y ago
As proven by <sys/tree.h>, the same approach can still be used to generate functions, even external, shared functions as opposed to static routines duplicated in each compilation unit. OpenBSD's <sys/tree.h>, at least, can generate both.
But list operation are so short and simple there's no benefit (especially if using the BSD approach) to generating and invoking functions. It just adds complexity.
If I had to guess, and based on memory (I first learned C programming by reading Linux and GNU project code), things ended up the way they are because like many early C projects Linux took the road of writing subsystem-specific list implementations using C function interfaces. Over time these interfaces were incrementally unified and improved, the quasi-generic implementations made more type-safe using the container_of and related constructs.
<sys/queue.h> seems to have been the product of a seasoned kernel hacker who took the opportunities provided by the huge 4.4BSD refactor to create and push a single, unified approach to be used across the kernel.
- codys 5y agoTo be clear, the linux approach doesn't need to "generate" functions: one can define the common operations as functions (and indeed, the linux kernel does this) that can be used for all list types. The list operations themselves (iterating, adding list nodes, removing list nodes) are all type safe (and can be placed in normal functions), the piece that gets funky is only examining the element content (which uses `container_of`). There's no reason to speculate on the origin of the the bsd and linux approaches here, and the speculation given is highly questionable.