⚡️ Почему обычный `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 — и проверка размера, индекса или лимита начинает работать против вас.