⚡️ Почему обычный `min(a, b)` в C может вернуть неожиданный результат
В C есть неприятная ловушка: если сравнивать signed и unsigned значения, компилятор может привести оба числа к unsigned.
И тогда отрицательное число внезапно превращается в огромное положительное.
Пример:
#define min(a, b) ((a) < (b) ? (a) : (b))
int x = -1;
unsigned int y = 10;
printf("%u\n", min(x, y));
Интуитивно кажется, что минимум — -1.
Но при сравнении x < y значение -1 приводится к unsigned и становится очень большим числом. В итоге сравнение работает уже не так, как ожидает разработчик.
Именно поэтому в Linux kernel макрос min() устроен хитрее. Он не просто сравнивает два значения, а сначала делает type check:
#define min(x, y) ({ \
typeof(x) _x = (x); \
typeof(y) _y = (y); \
(void) (&_x == &_y); \
_x < _y ? _x : _y; \
})
Ключевая строка здесь:
(void) (&_x == &_y);
Она заставляет компилятор проверить, что типы совместимы. Если один аргумент signed, а другой unsigned, такой код может превратиться в ошибку компиляции, а не в тихий баг в рантайме.
Это хороший пример системного C-подхода: лучше сломать сборку сразу, чем получить «правильный» код, который иногда считает неправильно.
В низкоуровневом коде такие мелочи решают очень много. Один неудачный implicit conversion — и проверка размера, индекса или лимита начинает работать против вас.
