Linus都要再三修正的max()宏是怎样演变的

发表于 2年以前 | 总阅读数：419 次

大家好，又与大家见面了，今天我们继续聊一聊关于Linux内核中的max()宏。

在前两篇文章中，小编的同门@梁金荣同学已经非常贴心地将Linux内核中的max()宏为我们逐项拆解，今天我们在之前两篇文章的基础上继续探讨一下max()宏的发展历史。

ps:小编也是刚接触Linux内核的小白，如果有问题希望大家留言指正~

想必大家对老版本内核中的max()宏已经有了深刻印象：前面的文章已经详细地说明了一个max宏是如何从

#define max(x, y) （x) > (y) ? (x) : (y);

转换成下面这样的(内核版本2.6)

define max(x, y) ({ \
typeof(x) _max1 = (x); \
typeof(y) _max2 = (y); \
(void) (&_max1 == &_max2); \
_max1 > _max2 ? _max1 : _max2; })

具体请阅读【Linux内核中max()宏的奥妙何在？(一) 】 [点击访问]

其实很多资料显示max宏是这样的...

define max(x, y) ({ \
typeof(x) _x = (x); \
typeof(y) _y = (y); \
(void) (&_x == &_y); \
_x > _y2 ? _x : _y; })

看出来差距了吗？其实就是把变量 _ x换成了_ max1, _ y换成了_max2

为什么要这样做呢？

假如内核程序员调用max()宏来比较如下两个数的大小时，这会导致意想不到的后果：

nt x = 3; int _x =6; 
max(x, _x)

Linux内核在设计max()宏时使变量名尽量变得复杂，同时要保证"见名知义"。这样做确实很大程度上避免了一些重名导致的安全问题，因为很少有程序员会这样调用：

max(x, _max1)

但这明显属于"换汤不换药"的解决方案，内核设计者不应该苛求程序员定义一个变量名称时考虑这么多。

既然重名问题可能引起上述问题，那么有机制可以使得命名永远不会重复吗？内核开发者朝这个方向做出了努力，小编查阅了4.15.9版本内核源码，发现max()宏悄然发生了变化:

**
* max - return maximum of two values of the same or compatible types
* @x: first value
* @y: second value
*/
#define max(x, y) \
__max(typeof(x), typeof(y), \
__UNIQUE_ID(max1_), __UNIQUE_ID(max2_), \
x, y)

#define __max(t1, t2, max1, max2, x, y) ({ \
t1 max1 = (x); \
t2 max2 = (y); \
(void) (&max1 == &max2); \
max1 > max2 ? max1 : max2; })

<linux/gcc-compiler.h>中给出了 __UNIQUE_ID 的定义

* Indirect macros required for expanded argument pasting, eg. __LINE__. */
#define ___PASTE(a,b) a##b
#define __PASTE(a,b) ___PASTE(a,b)

#define __UNIQUE_ID(prefix) __PASTE \
(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)

通过代码，我们可以大概了解内核是如何PASTE一个ID给待比较大小的两个数。这里给出GCC文档相关原文

COUNTERThis macro expands to sequential integral values starting from 0. In conjunction with the ## operator, this provides a convenient means to generate unique identifiers. Care must be taken to ensure that COUNTER is not expanded prior to inclusion of precompiled headers which use it. Otherwise, the precompiled headers will not be used.

从GCC文档可以看出每个值"Unique"的名称是通过GCC编译器中的 COUNTER 和运算符 ## 实现的。

至此，因为重名而引起max()宏异常已经成为了历史，因为每个数字都得到了独一无二的名称。

但是，这样并不完美

为什么呢?（这个关子卖的真是僵硬，上一篇大家都见识过了最新版本的max()宏了嘛，肯定知道介个并不是最新版本的max()宏啦）

了解过GNU C的同学应该知道有一个变长数组（VLA）这种神奇的存在，VLA在运行时其长度是不确定的，每次调用它都需要额外计算它的长度，增加了开销；更严重的是，内核的堆栈大小受限，而随意的使用VLA可能会使其长度飞速增长，攻击者如果可以以某种方式控制VLA大小，那么后果是可怕的。（想要深入了解GNU C的同学请访问http://www.nongnu.org/c-prog-book/online/）

所以内核设计者不鼓励在内核空间中使用VLA，但并没有禁止它。

不久之前，Linus宣称“使用VLA是愚蠢的！”并将VLA从内核移除提上了日程.…… 强大的GNU社区推出了Wvla工具提供GCC -Wvla选项，该选项可以在程序员声明VLA时发出警告。

然而不久又有人发现了BUG。。。他给Linus发了邮件：

The "sym" calculation is actually a fixed size, but since the max() macro uses some extensive tricks for safety, it ends up looking like a variable size. This replaces max() with a simple max macro which is sufficient for the calculation of the array size

他在声明一个定长数组的时候（看起来像VLA）使用GCC -Wvla时得到了警告，并认为GCC不够聪明，无法分辨VLA和定长数组。

然而Linus就是Linus，大神就是大神，他迅速找出了问题所在，并回复了邮件：

C标准在“常量值”和“常量表达式”之间进行了区分。数组维度必须是常量表达式，但max()宏的设计不符合这个规范。

于是，修订版本的max()宏出现了，请欣赏（内核版本4.8.5）

define __single_eval_max(t1, t2, max1, max2, x, y) ({ \
t1 max1 = (x); \
t2 max2 = (y); \
(void) (&max1 == &max2); \
max1 > max2 ? max1 : max2; })

#define __max(t1, t2, x, y) \
__builtin_choose_expr(__builtin_constant_p(x) && \
__builtin_constant_p(y), \
(t1)(x) > (t2)(y) ? (t1)(x) : (t2)(y), \
__single_eval_max(t1, t2, \
__UNIQUE_ID(max1_), \
__UNIQUE_ID(max2_), \
x, y))

#define max(x, y) __max(typeof(x), typeof(y), x, y)

可以看到内核代码中含有 “__builtin_constant” 字样，这说明对判断常量这件事做出了足够的努力，由于这个版本的max()宏使用了太多“逻辑短路”的宏技巧，对旧的编译器没有很好的支持。所以还需要继续迭代，但经过内核开发者的不断提交patch，目前至少声明一个定长数组时不会再偶然地发出“VLA警告”。

（对 __builtin 有兴趣的小伙伴请访问 https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html