Исправление bugfixer, (текущая версия) :
Кучу кода чинил где из-за чьего-то тупого «суну 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.
Исходная версия bugfixer, :
Кучу кода чинил где из-за чьего-то тупого «суну 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.