Теоретически, исходное значение не может быть представлено, если размер long меньше, чем значение в size_t, т.е. sizeof(size_t) > sizeof(long). Практически, в этом случае (с учетом того, что отрицательные значения в filelength — уже само по себе странно) значение в size_t никогда не может быть больше, чем, исходное значение в long filelength.
3 If the destination type is signed, the value is unchanged if it can be represented in the destination type (and
bit-field width); otherwise, the value is implementation-defined.
О, я не сразу понял масштаб бедствия.
Вы понимаете, насколько ужасен код, если посторонние люди даже с комментариями, не могут понять, что он должен делать? :)
А в этом случае вас не будут смущать ворнинги типа "преобразование к меньшему типу" в этой строке?
Вот и всё, намерения кода предельно ясны, и нет никаких предупреждений компилятора (который, кстати, правильно делает, указывая на места с нетривиальным поведением, как на потенциальные источники ошибок).
Но подождите, нужно еще прибавить единичку (оставим в стороне вопрос, зачем это нужно), и костыли, которые раньше неявно учитывали кейс с переполнением, теперь отсутствуют. (А что, если придется прибавить 2, а не 1?)
Придется немного усовершенствовать.
Перед выделением памяти стоит проверить, поместится ли требуемый размер в size_t, чтобы избежать труднодиагностируемых логических ошибок при дальшейшей работе.
Корень проблемы тут в том, что программисты пытаются решать совершенно не ту проблему, которую декларируют, от этого код покрывается костылями, граблями и абсурдопедией, подобной выше.
Кстати да, двадцать первый век на дворе, а винда до сих пор позволяет выволнение кода на страницах без PAGE_EXECUTE, причем на разных виндах это может работать, а может и нет. Ненависть. :)
интерфейс создания фильтров конечно же поражает своими возмжностями :)
ok, следующий вопрос - как сделать так, чтобы полученное и прочитанное через веб письмо не исчезало из инбокса доступного по pop3?
Вы понимаете, насколько ужасен код, если посторонние люди даже с комментариями, не могут понять, что он должен делать? :)
А в этом случае вас не будут смущать ворнинги типа "преобразование к меньшему типу" в этой строке?
Но хорошо, так еще проще.
Вот и всё, намерения кода предельно ясны, и нет никаких предупреждений компилятора (который, кстати, правильно делает, указывая на места с нетривиальным поведением, как на потенциальные источники ошибок).
Но подождите, нужно еще прибавить единичку (оставим в стороне вопрос, зачем это нужно), и костыли, которые раньше неявно учитывали кейс с переполнением, теперь отсутствуют. (А что, если придется прибавить 2, а не 1?)
Придется немного усовершенствовать.
Корень проблемы тут в том, что программисты пытаются решать совершенно не ту проблему, которую декларируют, от этого код покрывается костылями, граблями и абсурдопедией, подобной выше.
Коэффициент безопасности, посчитанный без учета обьема перевозок, времени в воздухе, и числа рейсов — это цифра, лишенная смысла.
ok, следующий вопрос - как сделать так, чтобы полученное и прочитанное через веб письмо не исчезало из инбокса доступного по pop3?