为何C语言中需将指针转为unsigned long？以Linux list_entry为例

Great question—this is a common point of confusion when moving from user-space C to kernel code, where we often do things that look "unsafe" by strict C standard rules. Let's break down why this pattern exists, even though C99 §6.3.2.3 notes pointer-to-integer conversions are implementation-defined (or undefined if the integer can't hold the pointer value):

6. Any pointer type may be converted to an integer type. Except as previously specified, the result is implementation-defined. If the result cannot be represented in the integer type, the behavior is undefined. The result need not be in the range of values of any integer type.

Key Reasons for This Conversion #

• Target Platform Certainty
  Kernel code isn't written to run on every possible C implementation—it's tailored to specific hardware architectures (x86, ARM, RISC-V, etc.). On all mainstream systems targeted by Linux, unsigned long has exactly the same bit width as a pointer: 32 bits on 32-bit systems, 64 bits on 64-bit systems. This means converting a pointer to unsigned long will always fit, so the "undefined behavior" case never applies here. The implementation-defined behavior on these platforms is well-documented and consistent: the integer value is the raw memory address the pointer holds.

• Byte-Level Offset Calculation
  The core of list_entry is calculating the base address of a struct from one of its members (the list node). To do this, we need to subtract the byte offset of the list node within the struct from the node's pointer.

  If we tried to do this with pointer arithmetic directly, we'd run into issues: pointer subtraction works in units of the pointer's type size, not bytes. By converting the pointer to unsigned long, we can perform simple integer subtraction on the raw address value, then convert back to a struct pointer. For example:

  #define list_entry(ptr, type, member) \
      ((type *)((unsigned long)(ptr) - offsetof(type, member)))
  

  This gives us the exact base address of the struct, no type-based arithmetic gotchas.

• Avoiding Type System Restrictions
  Strict C type rules can get in the way of low-level memory manipulation. Converting to unsigned long lets us bypass some type-checking hurdles that might cause compiler warnings or errors when working with generic list nodes (which are type-agnostic). Since the kernel prioritizes efficiency and control over strict standard compliance in these cases, this is a pragmatic choice.

• Historical Precedent and Consistency
  This pattern has been part of Linux kernel code for decades. Early compilers and hardware platforms relied on this kind of conversion for low-level operations, and it's become a standard idiom. Kernel developers know it's safe on supported platforms, so it's retained for consistency and readability (to anyone familiar with kernel code conventions).

At the end of the day, kernel code operates in a controlled environment where we can rely on specific implementation behaviors that would be risky in portable user-space code. This conversion is a perfect example of that pragmatism.

内容的提问来源于stack exchange，提问作者Metal Slime