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

@linux_education