[Homeros] Fwd: Ошибки в Voiceman

[Дмитрий Падучих]

Michael Pozhidaev:

>> Непонятно, правда, почему для таких параметров, как freq и lengthms
>> недостаточно типа int. В других случаях, наверное, тоже можно было бы
>> обойтись int.

MP> int знаковый.

Ну и хорошо, что знаковый. При работе с беззнаковыми типами требуется
быть более аккуратным, потому что он не очень интуитивно ведёт себя при
счёте близком к нулю (ты на эти грабли уже наступал, по-моему), и из-за
особенностей преобразования типов в арифметических выражениях C.
Поэтому, IMO, лучше пользоваться знаковыми типами, если в беззнаковых
типах нет надобности.

MP> Все остальные рассуждения здесь уходят в русло стремления к
MP> единообразию. Принято, что size_t - это для всего, что исчисляется
MP> количеством.

size_t - это значения, которые представляют размеры объектов. Реально
нужен только в том случае, когда заранее неизвестно, какие значения
может принимать величина. Например, функция malloc должна обрабатывать
запросы на создание объектов любого размера (не обязательно успешно). Но
если ты сам контролируешь размер буфера и знаешь, что размер
укладывается в диапазон int, то int подойдёт для индексации ничуть не
хуже, а то и лучше. Слово int проще писать и читать с помощью
синтезатора речи, он без проблем совместим с printf и подобными ей
функциями, не требует дополнительного внимания, как беззнаковые типы
(см. выше). То же самое относится и к ssize_t, плюс, как ты заметил,
ssize_t очень легко перепутать с size_t.

[...]

MP> Если быть особенно точным, то правильнее даже писать %zu, но, как я
MP> сейчас понимаю, это фича, которая может быть не везде, поэтому на
MP> текущий момент лучше сделать так, как ты прислал, рассматривая с точки
MP> зрения наилучшей совместимости.

Лучше int. Ну или unsigned long, если угодно.

MP> На x86_64 size_t уже long unsigned int, поэтому, как бы ты ни
MP> написал, без приведения типа будет всё равно неправильно. Ну а
MP> поскольку я писал именно на x86_64, код и получился таким, каким он
MP> получился.

Совпадение size_t с unsigned long на x86_64 вполне ожидаемо. Тем не
менее, в отсутствие гарантий, это всего лишь совпадение. Контракт
printf, sprintf и пр. заключается в том, что если ты пишешь %lu, то
должен обеспечить unsigned long в соответствующей позиции стека
независимо от совпадений. По крайней мере, я так это себе представляю.

-- 
Дмитрий Падучих