Comments 22
Номер 0 - кмк, классическая опечатка, вылавливается первым же тестированием, нет?
С асинхронным исполнением и гонками - да тоже по сути "классика", и в т.ч. как понимаю, одна из причин не любви Торвальдса к С++, ибо "нефиг" ;)
отсутствие проверок входных параметров .. кмк, очень спорный вопрос, т.к. тут больше вопрос "кто должен отвечать за контракт?" и самый тупой пример (с конференции в Севастополе 1990г) - проверка входных параметров внутри функции.. ну ок. Передаем в функцию числовую константу внутри цикла, вызываемого 100500раз, и? .. будем проверять константу на корректность на каждом вызове. А если контроль возложен на вызывающий контекст, то таки да, согласен - должно быть отражено в документации.
В целом, пасибки. Интересный статический анализатор, надо будет погонять на своих старых кодах (найти бы их ещё..) ;)
я рад что такой проггер как ты прочитал мою статью и разложил все по полочкам в номере 0) суть многих ошибок в том, что они просты до невозможности, их легко найти и исправить и... при этом они существуют в коде) про это и наш ТОП))) спасибо за коммент=)
Номер 0 - кмк, классическая опечатка, вылавливается первым же тестированием, нет?
Вероятно, мы первые и последние, кто протестировал эти проекты на ошибки)
В номере 9 использован абсолютно классический подход для множества выходов за пределы if блока через замену его на while или for и использование break, видел такое в коде много раз, так что ничего необычного.
Я такое через ‘[] () {…} ();’ и return где надо делаю. Имхо более очевидно чем через break. Плюс в таком же стиле можно сложную инициализацию констант делать.
Минусующие прокомментируют? Ассемблерный код получается аналогичный, читаемость - лучше, потому что нет непонятного цикла. Подобным образом, к примеру, устроен макрос QStringLiteral - это лямбда с моментальным вызовом, в котором есть инкапсулированная статическая переменная.
Все правильно, я тоже так делаю. Но номер 9 - это код из GCC, а он написан главным образом на, так сказать, "C с шаблонами", и while с break можно использовать в C коде, а лямбды - только в C++.
Моментальный вызов вообще весьма прикольный. Можно с его помощью делать затычки для тернарного оператора, когда один из операндов void, можно в pack expansion пихать для сложных операций.
Лямбды появились только в С++11, а у меня, например, появилась возможность их использовать в рабочих проектах только со сменой работодателя 5 лет назад, до того полтора десятка лет вел кроссплатформенные разработки и часть использовавшихся компиляторов поддерживала только С++03, и боли больше было даже не из-за отсутствия лямбд, а из-за отсутcтвия variadic templates и constexpr.
В номере 5 нет никакого UB. Данные ведь лежат последовательно и, следовательно, обращение vecs[0][4] эквивалентно обращению [1][0].
Не стоит предсказывать, как оно будет :)
Ложные представления программистов о неопределённом поведении.
Прошу прощения, но я не понял, что Вы имеете в виду.
Возвращаясь к описанному случаю:
1. Элементы массива расположены в памяти последовательно (по стандарту языка Си)
2. Обращение к элементу массива любой размерности осуществляется через смещение относительно указателя на начало массива. Поэтому оба выражения vecs[0][4] и vecs[1][0], в конечном счете преобразуются в *(vecs + 4). По сути, программист просто выполнил работу компилятора.
Напомню, мы говорим о чистом Си! Именно за такие вот трюки одни программисты его любят, а другие ненавидят )))
Делюсь с вами ярким примером UB для этого случая: https://godbolt.org/z/9nx83GE64
Так же с санитайзером, который так же заметил, что может присутствовать UB: https://godbolt.org/z/v7EE1jr8f
Таким образом, в процессе оптимизаций компилятором, да и компилятор у нас не один и каждый делает по своему, проблема может возникнуть, и мы будем долго бегать по коду пытаясь найти в чем же проблема. UB дело такое)
Undefined Behavior Can Format Your Drive =)
Но шутки в сторону -- если Си задуман как язык небезопасный, то зачем лишний раз полагаться на случай?
В 9 я бы обратил внимание на возвращаемое значение, которого в приведенном окончании функции нет.
тот самый код с GitHub: https://github.com/gcc-mirror/gcc/blob/master/gcc/ree.cc
возврат значений есть, проблема в отредактированном нами коде, поправил)
Тут и без статического анализатора все очевидно и код просто ужасный везде. Естественно, там есть ошибки. Сам весь такой код уже одна большая ошибка.
Чего стоят только вложенные if, макросы, лучше бы показывали примеры ошибок в красивом идеальном коде. Где кроме найденной ошибки нет ни одной проблемы из разряда «так делать нельзя».
Я возможно не смогу доказать что статический анализатор вещь абсолютно нужная в каждом доме, но у меня есть пара мыслей на этот счет)
Чаще всего код пишут простые программисты, которым нужен результат. Коммерция или нет, чаще приоритет в процессе написания проекта отдается в эффективность выполнения кода и скорость его написания. Грубо говоря, если ты занимаешься коммерцией, для тебя главное чтобы твой продукт работал и приносил деньги. Так же, если ты пишешь нечто бесплатное, первое что ты делаешь это пишешь работающую программу, чтобы ей могли пользоваться. Только потом уже идет процесс оптимизации. Если ты будешь идеально его писать с самого начала то это займет намного больше времени и сил. Только после того как программа написана ты начинаешь оптимизировать программу, ты можешь её переписать хоть с нуля, но главное что твоя программа уже работает и используется.
Дебажить большие проекты на самом деле очень трудно. Часто в проекте не остается никого из программистов писавших код. И вот ты приходишь в компанию, начинаешь копать какой ни будь файлик в котором более 50тыс строк кода и через пару часов ты уже сидишь и на автомате начинаешь пытаться что то найти. Чем дольше ты листаешь, тем труднее искать ошибку. Анализатор тебе сразу показывает возможные проблемные участки кода, и ты сразу можешь начать исправлять ситуацию. Опять же есть специальная база по ошибкам и ты можешь там глянуть приблизительно в чем может быть проблема и быстро проверить нет ли где проблем в тех или иных файлах.
Что интересно, все ошибки найдены в крупных проектах. Как мне кажется, вовсе не джуны эти проекты разрабатывали) Суть: код пишут люди, и мы по массе причин не идеальны и допускаем ошибки. Самые частые ошибки - очень простые. Те же самые копи-паст и сравнения.
можете ознакомится если интересно:
Зло живёт в функциях сравнения
Последствия использования технологии Copy-Paste
И это только про простые ошибки)
Предновогоднее шоу: Топ 10 ошибок в C и С++ проектах в 2023 году