YM> Friday October 18 2013 11:15, Pavel Gulchouck wrote to Roman Trunov: PG>> появляются новые предупреждения (как в том примере, что ты привёл), а PG>> во-вторых, исправление предупреждения для одного PG>> компилятора/системы/архитектуры может привести к появлению PG>> предупреждений или ошибок для другого компилятора/системы/архитектуры. PG>> Если там прописать intptr_t - точно ли оно будет собираться и без PG>> ошибок работать под mingw, например?
YM> Hу это-то как раз просто обойти - добавить #define intptr_t int * под соответствующие оси/компиляторы, которые сей тип YM> не знают.
Заранее неизвестно, какие знают, а какие нет. Сейчас может не знать, а в следующей версии уже узнать, и будет ошибка компиляции. Или вот, как показал Роман, в VC200 _findfirst() возвращает long - если прописать intptr_t, там будет warning, а возможно, и крэш, если вдруг где-то окажется, что long 64-битный, а intptr_t 32-битный.
YM> И везде при работе с размерами использовать тип size_t, а не int.
Тоже плохо. Например, у fseek() второй параметр именно long, а никак не size_t. Если ему передать size_t, будет предупреждение, а если этот size_t будет больше 2G, то и ошибка в поведении binkd. Есть ещё socklen_t, например. Точнее, бывает, что он есть, а бывает, что его нет. :(
YM> Равно как не использовать int для хэндлов, сокетов etc. int оставить только для "числовых" вычислений, которые не YM> зависят от разрядности системы.
Не использовать int для хэндлов - очень уж радикально. Функции open()/read()/write()/close() используют именно int, и это закреплено в стандарте ANSI C.
YM> PS будет время на след. неделе - аккуратно перелопачу код на предмет всех варнингов 64бит режима и выложу результат.
Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5 * Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
