- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
int size;
size = EXPR;
if (size > INT_MAX || size <= 0) {
return NULL;
}
// ...-
Си / Говнокод #17154
+133
Ндя. Семь лет уже. Теперь всё понятно...
Запостил:
bot,
23 Ноября 2014
Follow us!
Вот всяко компилятор посмотрел на это условие как на говно, и выпилил его.
с переполнениями по большей части страдают только те кто абстрагируют и враппят все подряд, потому что теряется смысл и контекст чисел.
тот же calloc(). в доморощенной реализации 10+ лет назад я влепил по тупому ограничение 1МБ на размер аллоцируемого буффера. в конторе уже давно не работаю - а бывшие коллеги расказали что за эти годы, благодаря моей проверке, некоторое количество серьёзных багов споймали.
это Вы про флажочек в FLAGS?:)))
Флажочек плох тем, что его нужно проверять постоянно. Если не проверяем - получаем неверный результат в результате переполнения. Если проверяем - получаем уменьшение производительности.
Это в нашем любимом x86.
Но есть другие архитектуры процессоров. Например, в БК-0010 стоял проц, совместимый по системе команд с PDP-11. Так вот там при переполнении не только выставлялся флажок, но и происходило аппаратное прерывание: переход на подпрограмму по адресу, указанному в специальном векторе прерывания.
Что это даёт? При отсутствии переполнения производительность не ухудшается ни на йоту! При наличии переполнения, если нам не нужно на него реагировать, просто пишем команду возврата из прерывания в подпрограмме: цена выполнения - два перехода, туда и обратно.
Ага... Вот только в защищенном режиме получается довольно прикольный маршрут.
А флажочек с хинтом для предсказателя переходов тоже ничуть не ухудшит производительность.
Это уже не важно, ведь произошла критическая ошибка, на которую нужно реагировать, нормальный ход вычислений прерван.
А флажочек с хинтом должне быть в архитектуре процессора. Если такого нет - упс.
В целом согласен - варианты могут быть разные.
А вот опять вопрос: неужели какой-нить линт на это не ругнулся?
В Вашем -- нет?
Ладно. Пусть с ним, с линтом. Ну а как можно всерьез написать if intVar > MAX_INT?
5.4.0 проваливала тесты, но была выпущена:
http://www.reddit.com/comments/qeq7k/php_540_ships_with_82_failing_tests_in_t he_suite/
--Это ожидаемые варнинги и ожидаемые падения
--А, ок
Тесты это маркетинговый интерпрайз буллщит. Я 20 лет пишут без тестов и всё в порядке
Незачем совершенно. Вообще всё начиная со структурного программирования Дейкстры 70х и заканчивая async'ами нашего времени -- все это не нужно.
Люди отлично писали на Коболе в 1960м, и всё у них работало.
А сейчас XP, ООП, Agile, BDD, TDD, ужас!
Смысл современного тестирования - это взгляд на мир сквозь розовые очки. Если передаём true, то должно вернуть false. Смешно же. А если передадут нул, или, не дай Бог, структуру какую-нибудь?..
Получается, что вероятность наступления капута, какому-нибудь, самолёту, повышается, если вдруг в закрылки ударит ветер с силой и под углом, значения которых не предуматривались в этом самом тестировании...
Автор комментария был навечно забанен за еретическое неприятие юнит-и-прочих-модульных-тестов. Страйкер: 2014-11-24T20:49:34
Или вот например некоторые говорят: используйте статическую типизацию. Это, дескать, помогает отлавливать ошибки, писать и читать код. Но ведь все ошибки всё равно не отловишь, а код писать всё равно надо с умом. Потому я в java и C# программах всегда использую Object или Map/Dictionary, а в языках вроде Python тоже dict: сложил, и на месте разобрался.
Или вот например недавно все помешались на MVC и его производиных. Хотят, видите-ли, разделать модель, поведение и вью. Какая чушь!
Вот тут серьезный программист объективно объяснил что это не нужно: https://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html
Автор приглашен на конферению в качестве докладчика по теме "современный подход к разработке ПО"
Анонимус неломаем.
А вот так работает: https://archive.today/hXEiI
Видели там файл add.html?
Он прекрасен же!
Кроме того роутер не решает всех проблем, а раз так -- значит не нужен.
И фреймворки не нужны, и ОРМ не нужны, и MVC не нужно, и IDE не нужны, и тесты не нужны -- ничего не нужно, на самом деле! Потому что ничего из этого не решает всех проблем!
А теперь я сразу домой и windows переставлять до утра. В некоторые дни мне за ночь удается семь раз ее переставить, родимую.
Возможно вы имели ввиду add.php?
У нас где-то в недрах старого сайта тоже валяются активные "хтмлки" на пёрле...
Это помогает мгновенно ловить опечатки и не писать тесты на то, что может поймать компилятор.
А если язык позволяет, можно ещё и часть семантики предметной области зашить в типах, чтобы бессмысленные операции невозможно было скомпилировать.
Но для вас, это, конечно, не аргумент, вам небось "и PyCharm всё подчёркивает".
Мне вот тоскливо писать что-то размером более одного скрипта на динамической питушне.
А случай, когда одна переменная должна принимать и число, и строку, и указатель на функцию, и всякую составную питушню, можно придумать разве что с натяжкой. Чтобы пробегать в цикле по элементам полиморфной коллекции? Но откуда такая коллекция может взяться?
Из базы данных, если запрос не известен на этапе компиляции.