История изменений

Кучу кода чинил где из-за чьего-то тупого «суну int по дефолту» были баги.

Я уверен что чинил не меньше связанных с чьей-то идеей «8/16 бит здесь хватит». Повторюсь - нужны довольно веские причины откланяться от дефолта, имхо.

Как минимум, стоит подумать нужен ли тебе знак у этого числа.

Где гарантии что никто по дороге не засунет int в unsigned? А потом начинаются проблемы с implicit conversions, -1 suddenly becoming a very large value, etc. Проще оставаться в одном домене, в данном случае - signed integers.

последствие этого тупизма прямо в libc - тип возврата snprintf

Вы о том что оно int а не ssize_t? Как часто Ваши строки не умещаются в 2GB?

И таки мне видится что это всё именно наследие со времён K&R.

Это прямое следствие ABI, и предположения «int» - это самый быстрый integral type on a target platform, register size basically - в частности в случае x86 ints возвращаются в eax, что dirt cheap.

Кучу кода чинил где из-за чьего-то тупого «суну int по дефолту» были баги.

Я уверен что чинил не меньше связанных с чьей-то идеей «8/16 бит здесь хватит». Повторюсь - нужны довольно веские причины откланяться от дефолта, имхо.

Как минимум, стоит подумать нужен ли тебе знак у этого числа.

Где гарантии что никто по дороге не засунет int в unsigned? А потом начинаются проблемы с implicit conversions, -1 suddenly becoming a very large value, etc. Проще оставаться в одном домене, в данном случае - signed integers.

последствие этого тупизма прямо в libc - тип возврата snprintf

Вы о том что оно int а не size_t? Как часто Ваши строки не умещаются в 2GB?

И таки мне видится что это всё именно наследие со времён K&R.

Это прямое следствие ABI, и предположения «int» - это самый быстрый integral type on a target platform, register size basically - в частности в случае x86 ints возвращаются в eax, что dirt cheap.