Вышла новая версия статического анализатора кода cppcheck 2.12, позволяющего выявлять различные классы ошибок в коде на языках Си и Си++, в том числе при использовании нестандартного синтаксиса, типичного для встраиваемых систем. Предоставляется коллекция плагинов, через которые обеспечена интеграция cppcheck с различными системами разработки, непрерывной интеграции и тестирования, а также предоставлены такие возможности как проверка соответствия кода стилю оформления кода. Для разбора кода может применяться как собственный парсер, так и внешний парсер...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59764
Кто-то использовал? Мнение?
Smatch на 2 головы полезнее.
ты вот это васяноподелие пытаешься рекламировать?https://github.com/error27/smatch
туда твой однострочный PR приняли? эйфория?
Сам ты васяноподелие. Буквально. А сообщения там куда полезней были, цппчек ничего не видел.
Мнение: любой статический анализатор лучше отсутствия статического анализатора.
Исправлять надо причину появление ошибок, а не вылавливать их как блох уже после того как они появились.
Вот так и напиши в своём заявлении по собственному.
Я не пользуюсь дырявыми языками родом из 50-х.
Соответственно с микроконтроллерами не работаете, производительные модули не используете, про драйвера молчу.
Задачи то разные бывают.
Десктопное приложение и я на С++ добровольно писать не стану.
Electron гуру? JS сенсей? CSS будда?
Ом мани падме хум
Микрософт Ворд печатник.
> Я не пользуюсь дырявыми языками родом из 50-х.Гордый пользователь редокса и фуксии на десктопе? %)
>Я не пользуюсь дырявыми языками родом из 50-х.Напиши это в резюме и выдели жирным.
Всегда так делаю.
> Исправлять надо причину появление ошибок, а не вылавливать их как блох уже
> после того как они появились.Ну да, нужно просто начать писать код без ошибок. Делов-то.
Или использовать известный безопасный язык со строгим конпелятором.
То есть Crab.
Есть ещё мелкие опечатки, описки, которые компилятор в вполне скомпилирует, а анализатор может на подобное выдать сообщение.
> Исправлять надо причину появление ошибокТак можно и в протворечие с резолюции 260 (III) запросто войти.
Если самосборный использовать, подавив лишниее сообщения, то вполне полезен, и не раздражает, а в стоковом виде среди спама заметить что то подозрительное мало реально.
А ключами не все управляемо, сразу весь тип проверок или включается или выключается.
а грепнуть лишнее не вариант?
> а грепнуть лишнее не вариант?Можно, если любите длинные выражения писать, и нужно если ещё и любите их потом править.
И в награду будет ощутимое снижение компиляции.А более по делу, есть еще атрибуты, на которые cppcheck забивает, и выдаёт спам. Но в этом случае вывод то нефильтуем никаким грипом. И можно или вырезать всё или оставить всё.
Туда же, в cppcheck,врезается и список исключений на имена, конструкции с которыми лучше игнорировать.
Ну, Си используется для микроконтроллеров, и тамошние трюки он в шоке.
> Ну, Си используется для микроконтроллеров, и тамошние трюки он в шоке.Фирмару надо нормально писать - тогда оки все. Я проверял - у меня практически без варнингов, кроме разве что bug-hunting mode получается. А за трюки в критичном софте - воздается. Жесткими фэйлами. У него bug-hunting - это exploratory mode когда можно получить сообщения которые не проблема, но могут и быть проблемой.
И если фильтровать вывод анализера - вы как раз баги и пролюбите. Код надо фиксить, а не...
> Фирмару надо нормально писать
> у меня практически без варнинговЯ не Ардуины, а о более реальных крупных проектах для микроконтроллеров.
От компилятора то варнингов и нет, они или хинты есть от cppcheck, и часто грубо не по делу, то есть спам.> И если фильтровать вывод анализера - вы как раз баги и пролюбите.
Не думае те же Вы, что cppcheck святее Папы Римского? Нет конечно. Но дополнительную проверку делает.
И особенно полезен, когда часть кода писал не сам.> Код надо фиксить, а не...
Да ну? Атрибуты убрать? В embedded это даёт заметный сразу эффект ;)
Или аппаратные фичи не использовать, потому что анализатор о них понятия не имеет?А на обычное десктопное ПО анализатор в идеале ругаться не должен, ибо на подобных исходниках и тестировался.
> Я не Ардуины, а о более реальных крупных проектах для микроконтроллеров.У ардуины код крупный как раз - 100500 либ и черт его знает что там про них чекер говорит. А то что вы развели г@вна в проекте - мало ли, может слава Тойоты вам покоя не дает.
> От компилятора то варнингов и нет, они или хинты есть от cppcheck,
> и часто грубо не по делу, то есть спам.Если кодить используя приемы antibug coding и придерживаться идей близких к MISRA, тогда большая часть варнингов от сабжа вполне полезные. Да и компилеры вы небось юзаете столь же разухабисто. Хотя-бы -Wconversion ваш супер-код переживает без варнингов? Компилера, ага. Если мало - дайте все ключи из бложика Cyan хотя-бы.
>> И если фильтровать вывод анализера - вы как раз баги и пролюбите.
> Не думае те же Вы, что cppcheck святее Папы Римского? Нет конечно.Видел я что эти святоши вытворяют, и заманался чинить уже. Так что нет, аргумент не котируется.
> Но дополнительную проверку делает. И особенно полезен, когда часть кода писал не сам.
Да и самого себя проверить лишний раз совершенно не лишне. Си такая штука что клювом клацать не стоит. Особенно если уже подустал и проч - можно и протупить случайно.
>> Код надо фиксить, а не...
> Да ну? Атрибуты убрать? В embedded это даёт заметный сразу эффект ;)Что-то не помню чтобы сабж сильно пиндел на атрибуты. Ну и да, совсем убрать их конечно не получится.
> Или аппаратные фичи не использовать, потому что анализатор о них понятия не имеет?А в каком месте анализатор вообще на вот именно аппаратные фичи сами по себе возбухает?
> А на обычное десктопное ПО анализатор в идеале ругаться не должен, ибо
> на подобных исходниках и тестировался.Да он и на эмбедовке довольно прилично работает. Если не выделываться с трюкачеством, за что воздается. Например тем что соседний кодер трюкачество не понял или понял неверно.
когда у тебя на 1 ошибку 10000 бесполезных советов, то такой статический анализатор это геморой и явно НЕ дейли инструмент
> когда у тебя на 1 ошибку 10000 бесполезных советов, то такой статический
> анализатор это геморой и явно НЕ дейли инструментИли как вариант - д@рьмовый кодер, возомнивший себя самой умной клавой на глобусе. С сишкой это почему-то очень часто случается. И потом у таких в коде куча CVE и просто багов. А когда суперкод начинают тыкать палочкой - вооооон там майнтайнер XFS с такого счастья сбежал в панике, за такими кодерами разгребать устал как раз.
> С сишкой это почему-то очень часто случается.О, так это их стандартное поведение. Они же типа ылитка))
А потом начинается или "это неправильный сишник, настоящий бы так никогда не написали", или "не, ну все так ошибаются, а что вы хотели??"
>> С сишкой это почему-то очень часто случается.
> О, так это их стандартное поведение. Они же типа ылитка))
> А потом начинается или "это неправильный сишник, настоящий бы так никогда не
> написали", или "не, ну все так ошибаются, а что вы хотели??"Ну вот я немного подустал за ними править отрицательные индексы, левую математику и полный похрен на проверку аргументов на входе - и имею заметить что смертные как-то не очень хорошо овладели инструментом богов. Откуда вон те сомнения. Даже матерый олд иногда может створить полнейшую хрень. И поэтому совсем не лишне если инструмент подстрахует подсветив подозрительный код.
Устал - гоу на пенсию, нытик-неосилятор. Пылинку в чужом коде все горазды заметить, покажи свой код.
> Устал - гоу на пенсию, нытик-неосилятор. Пылинку в чужом коде все гораздыНу если buffer overrun при определенных аргументах, или факап в математике выдающей левак - пылинка, я уж боюсь себе представить что у вас крупнее. Полное стирание флехи с фирмварью чтоли, без предупреждений? Сигейты 7200.11 одобряют.
> заметить, покажи свой код.
Я его регулярно сабжу и показываю. И не имею особых проблем с ним :). А вы можете покупать сигейты 7200.11 и ездить на непатченой тойоте, там как раз пылинок - есть.
Сразу видно человека который фирмварь никогда не писал, иначе знал бы что hardware сишники, кроме костылей и велосипедов никогда ничего не пишут, потому что те кто разрабатывают железо, делают его через задницу, и вот эту задницу нужно подтирать софтом.
💯 пудов.особенно такое проявляется конда и "платку сам разводил и фирмварю сам писал"
зачем мне писать и править длинные выражения, что такое выражени, что такое снижение компиляции?короче, я этот набор слов с рандомными запятыми не распарсил
Если у вас снижена компиляция, то нужно всего лишь раз в день принимать советское, копеечное...
> Кто-то использовал? Мнение?Вполне работоспособная и полезная штука, подтянула качество кода моим проектам и выловилось несколько проблемных мест. Вполне себе аргумент "за".
Из бесплатных - лучший. Но полное г. по сравнению с платными.
быстро развивается
Сначала слепили дврявый язык, а теперь думают как избавить код от ошибок 🤣
Другие написали точно такой же дырявый язык и пытаются всем внушить что он не дырявый. 🤣
Пруфы дырок будут или только газификации луж
>Сначала слепили дврявый язык, а теперь думают как избавить код от ошибокЖдем пруфы дырок.
Именно поэтому Раст не нужен. Пока проблемы решаются через анализаторы кода, отдельное решение, не совместимое с прежней кодовой базой, не нужно.
Не решаются. Количество ИЗВЕСТНЫХ уязвимостей не даст соврать. А сколько ещё НЕИЗВЕСТНЫХ....
То же самое применимо к новому языку. А сколько у него еще НЕНАПИСАНЫХ ошибок...
> Именно поэтому Раст не нужен. Пока проблемы решаются через анализаторы кода,Rust - не даёт прострелить ногу, пока не используется unsafe. Ну, по крайней мере, концептуально должен не дать.
> решение, не совместимое с прежней кодовой базой, не нужно.
А чисто исходники на Си, и тем более C++, но написанные под разные их стандарты или реалиции компиляторов, архитектуры, типа переносимы без их правки. А уж проявление граблей при переносе и вовсе непредсказуемо, в том числе анализаторами.
Предположим в очередной стандарт Си добавят фичи из Rust, так на несовместимость исходников и слова не скажут, ибо не хочешь - не используй.
А тогда с Rust что не так? Там претензии не столько к менее читаемому синтаксису, сколько к системе сборки и зависимостям.
std::unique_ptr.
С разморозкой, появился в 2011 году
угу,
а куча проектов все еще на более древних версиях
и переходить они не собираются, ибо костылей и ub там столько, что проще забить
Раст переписать в принципе невозможно. Давай ещё аргументов.
это конкретно std::unique_ptr появился тогда, но никто не мешал до него написать свой
Мелало отсутствие мув-семантики.
И как тебе этот юникпоинтер не позволит изменить значение из разных потоков?
Я как практикующий сишник скажу, что в реальности не всё так, как ты обрисовал. Ты курнул?
Ты всегда используешь ансей в расте, зачем тогда Раст. Ни один растовик пока что на этот вопрос не смог внятно ответить.
Rust всегда Rust, что safe, что unsafe: правила одни и те же и там и там. В unsafe блоках ты берёшь часть проверок на себя, только и всего. В safe части ты можешь расслабиться, в unsafe приходится напрячься, но unsafe блоки пишутся максимально просто — так, чтобы без особых трудностей следовать правилам, а запутанные вещи делаются в safe части.
> Ты всегда используешь ансей в расте, зачем тогда Раст.Ты всегда пишешь чушь?
> Ни один растовик пока что на этот вопрос не смог внятно ответить.
Внятно - это в рамках персонально твоей, альтернативной логики и реальности?
> Ни один растовик пока что на этот вопрос не смог внятно ответить.Может ты просто не в состоянии осилить ответ?))
Ты в танке? Он же ясно сказал, что на этот вопрос растаманы не могут дать внятного ответа.
Раст, по факту, это один большой стат. анализатор.
Чем бы ни страдать, абы на язык с нормальным компилятором не переходить, в котором бОльшая часть ошибок ловится на этапе компиляции без всяких дополнительных телодвижений.
необучаемость, сэр.
столько не живут, сколько ты будешь свой говнокод переделывать под хотелки компилятора
А под хотелки статического анализатора не нужно переделывать, да?
Как только он начинает выпендриваться на него кладется болт и хотела идёт в исключения.
Звучит надёжно и очень безопасно
Уже ходишь в бронетрусах?
> Как только он начинает выпендриваться на него кладется болт и хотела идёт в исключения.А потом вы такой садитесь в тоету с непатченым ECU и наслаждаетесь острыми ощущениями... правда, сможете ли вы ими поделиться с окружающими - вот это как повезет уже. Как показали натурные эксперименты, везло не всем.
да, не надо, потому что он указывает на косяки, а не на шизофазию головного мозга "разработчиков" раста и их видение реальности. эталонное шашечки и ехать
Ну Herb Sutter уже пишет новый cpp2.. Очнулись таки
https://github.com/hsutter/cppfront
Страуструп тут недавно выступал и совершенно точно подметил, что те, кто думает, что корректность программы исчерпывается правильной работой с памятью, не понимают примерно ничего в этой жизни https://www.youtube.com/watch?v=eo-4ZSLn3jc
Страуструп не понимает что UB — это не "некорректность". Суть не в том чтобы писать без ошибок, смысл в том, чтобы писать программы хотя бы синтаксически корректные, то есть без UB.
Пионеры не в состоянии понять, что UB - это следствие разнородности аппаратных платформ, с которыми C++ должен уметь эффективно работать непосредственно. И когда их любимый пионерский язычок натыкается на целочисленное переполнение в релизной сборке, он ведет себя точно так же неопределенно, как и C++.
> пионерский язычок натыкается на целочисленное переполнение в релизной сборке, он ведет себя точно так же неопределенноА вот и нет. Что для signed int, что для unsigned int выполняется two’s complement wrapping.
Т.е. нет никакого UB, потому что результат выполнения будет однозначный, в отличие от плюсов и сишки.
https://github.com/rust-lang/rfcs/pull/560Читайте маны, а не плодите мифы!
Вы либо крестик снимите, либо трусы наденьте: если вы пишете, что у вас нет runtime и overhead, то не пишите, что у вас нет UB, и наоборот - если у вас нет UB, тогда у вас есть runtime и/или overhead, которые обеспечивают поведение согласно вашим хотелкам на платформах, у которых поведение другое.
> если вы пишете, что у вас нет runtime и overhead, то не пишите, что у вас нет UBOh, my sweet summer child... Наличие UB не дает магического прироста скорости. Оно лишь дает право выстрелить себе в ногу, написав некорректный по определению код, а компилятору - право закрыть на это глаза.
Именно поэтому людям и приходиться использовать с C и C++ статические анализаторы: чтобы выловить свиней, заботливо подложенных создателями и комитетом C/C++ в свои убогие дырявые языки.
неофиты неисправимы...если ты знаешь, как работает комп, на котором ты будешь запускаться, ты просто берёшь и делаешь UB в угоду производительности, и ничего в этом криминального нет. нет никакой необходимости обходить формальное UB и писать более медленный код, если ты уверен, что имеющийся будет работать
Боже... вот из-за таких как ты, нынешний софт такой багованый...Открываем ISO/IEC 14882:2020, пункт 3.28 undefined behavior
"Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."
Сам осилишь или перевести?
Наверное не нужно - ты же такой умный, знаешь как работает комп!
Можешь определить какое UB формальное, а какое нет)))А потом твой прекраснейший быстрейший код, может превратиться в невалидную хрень просто при смене компилятора или даже при смене мажорной версии компилятора. И это я молчу про разные низкоуровневые изменения типа фиксов микрокода и тд.
"Because correct C++ programs are free of undefined behavior, compilers may produce unexpected results when a program that actually has UB is compiled with optimization enabled"
Ну так по этому определению твой любимый пионерский язычок, в котором якобы нет UB, может либо запаниковать, либо не запаниковать при переполнении. Всё в зависимости от того, с какими опциями будет вызван компилятор. Ещё раз: это не про C++, а про твой язычок, в котором, якобы, нет UB.
Нет, речь не про раст, и даже не про с++.
А про подход, что "ты просто берёшь и делаешь UB в угоду производительности, и ничего в этом криминального нет"
Тебе в с++ стандарте черным по белому написали чем это грозит. Но ты все равно считаешь, что умнее разрабов стандарта и такой быдл0к0д имеет право на жизнь!> может либо запаниковать, либо не запаниковать при переполнении
Facepalm... Дело не в том, что оно запаникует или нет. А в том, что поведение integer overflow описано и зафиксировано. А оно уже может быть любым, главное однозначным.
Поведение integer overflow описано и зафиксировано и в C++ ТОЖЕ! Только описано и зафиксировано оно не для компилятора, а для конкретной платформы. И на конкретной платформе конкретное поведение является полностью определенным. Далее кому надо - берут и используют библиотеку, предоставляющую нужный баланс гарантий и производительности, e.g. https://github.com/dcleblanc/SafeInt/blob/master/helpfile.md
Благо проблем с расширением C++ библиотеками, в отличие от известно пионерского языка, почти нет.
> и в C++ ТОЖЕ!А вот теперь пруфы для signed integer overflow хотя бы для пары платформ (ссылки на доки подойдут).
И не нужно говорить что это другое, в комменте выше я писал про signed.
Пожалуйста: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html
А теперь расскажи чем пионерский язычок в этом плане лучше, если он может либо генерировать панику, либо не генерировать панику - всё в зависимости от опций компилятора.
> Поведение integer overflow описано и зафиксировано и в C++ ТОЖЕ! Только описано и зафиксировано оно не для компилятора, а для конкретной платформы.Нет, дружок, не зафиксированно. В стандарте C++ черным по белму написано, что signed overflow это UB. На любой платформе. Иначе это было бы не UB, а implementation-defined behavior.
> И на конкретной платформе конкретное поведение является полностью определенным.
Не, не является. UB - это UB на любой платформе.
В общем, как всегда на опеннете: некомпетентный в C и C++ "эксперт" понятия не имеет о проблемах этих языков, но во всю воюет против Раста.
Ещё раз: UB в этом контексте означает то же поведение, что и в пионерском язычке. В зависимости от опций компилятора.When signed integer arithmetic operation overflows (the result does not fit in the result type), the behavior is undefined: it may wrap around according to the rules of the representation (typically 2's complement), it may trap on some platforms or due to compiler options (e.g. -ftrapv in GCC and Clang), or may be completely optimized out by the compiler.
> UB в этом контексте означает то же поведение,UB в этом - и в любом другом
- контексте не может означать какого-то поведения. Как бы само название "неопределенное поведение" говорит об этом прямым текстом, но тебе ведь спорить - как с горы катиться.Извини, чел, но чтобы понять, зачем существует Раст, нужно знать о проблемах C/C++ - а ты в этой теме не в зуб ногой.
Я на C++ деньги зарабатываю, а ты пионер, который пересказывает проповеди евангелистов. Если тебе ссылки на документацию выше не говорят о возможности задания строгого определенного поведения в GCC и Clang (а также в любых других комбинациях компиляторов и платформ), то ты просто не понимаешь, что там написано. UB в C++ означает только то, что стандарт не определяет поведение в данной конкретной ситуации. Это не значит, что поведение будет обязательно неопределено для конкретного компилятора и платформы, а ровно наоборот - просто оно может отличаться между платформами и компиляторами.
> UB в C++ означает только то, что стандарт не определяет поведение в данной конкретной ситуации.Это не так. Ты сейчас говоришь про 3.29 unspecified behavior
"behavior, for a well-formed program construct and correct data, that depends on the implementation"
Вот оно зависит он конкретной реализации. При этом код остается валидным и на это поведение можно завязываться.А UB делает код невалидным. В след. версии компилятора они мог вообще дропнуть UB кусок во время оптимизации и будут абсолютно правы. То что в компиляторы добавили флаги-костыли для затыкания UB - это просто от безысходности - количество быдл0кодеров, которые кладут болт на стандарты превышало все разумные пределы, а кодовая база была уже написана. И это вряд ли изменится, потому что исправив это - получат кучу нытиков "дисят лет работало, а типеря сламалася!!11"
> Я на C++ деньги зарабатываю
Да я и не сомневался)) А таких как ты много...
Я говорю так, как оно есть, но я пытаюсь что-то донести до пионера-фанатика, который не понимает ни русского, ни адглийского, ни элементарного здравого смысла, а несёт какую-то религиозную пургу, чтобы возвысить свой пионерский язычок и приписать другим языкам недостатки, которых у них нет. По факту у тебя просто одна реализация компилятора и нет никакого стандарта, так что на стандарты ты будешь ссылаться тогда, когда он появится и ты поймешь для чего стандарты нужны.
> приписать другим языкам недостатки, которых у них нетЗабавно было бы услышать, почему тогда 70% всех уязвимостей - это именно работа с памятью в C и C++. Действительно: если в C++ нет недостатков, то выходит, что Rust могли придумать лишь дураки-пионэры, которые об этом не знали, так ведь?
> на стандарты ты будешь ссылаться тогда, когда он появится и ты поймешь для чего стандарты нужны.
Ну так у C/C++ они уже есть. И нужны они, очевидно, для того, чтобы опеннетные эксперты трактовали их так, как захочется - в зависимости от уровня своей некомпетентности.
Дорогой пионер, стандартов C++ уже 6 штук и на подходе 7-й. И различаются некоторые из них между собой не меньше, чем 2 разных языка. А ты пишешь про какую-то работу "с памятью в C и C++". C++ успешно эволюционирует и проблемы в нём успешно устраняются, чего не скажешь о пионерском язычке, код браузерного движка на котором оказалось легче выкинуть и переписать с нуля (https://www.opennet.me/openforum/vsluhforumID3/131470.html#52 ), нежели пытаться исправить - ещё до выхода первого стандарта язычка. И это при том, что сам язычок изначально разрабатывался компанией Mozilla именно для этого браузерного движка. А на C++ код поддерживается и развивается десятилетиями, благодаря чему ты здесь можешь писать всякую ерунду.
И все так счастливы поддерживать этот прекрасный язычок что, как ты и сам заметил, одни изобрели Раст, другие карбон и го. От скуки наверное?
Дорогой непионер, мы все уже давно поняли твою позицию и что ты из себя представляешь.
И про быдлокодинг, и про "а так сойдет", и про болт на стандарты.
Спасибо, мы достаточно видели таких и их кода... Можешь не продолжать позориться.
В дальнейший диалоге смысла не вижу. До скорой встречи в очередной CVE в дыряшке.
Не забудь принять стандарт ISO пионерского язычка и сменить "дыряшку" на реактос с сервоприводом прежде чем следующий коммент строчить, любитель стандартов.
скомпиляй ядро без расширений GNU для С, и тогда что-то рассказывай, любитель стандартов.Не стандарт, а убожество. Невозможно сделать ядро (казалось бы С для этого и придумали) чтоб не попользоваться нестандартными расширениями компилятора.
> чтоб не попользоваться нестандартными расширениями компилятораВы думаете это случайно так? По недомыслию разработчиков стандартов? Вы то умнее их и так бы не сделали?
я не знаю по какой причине стандарт такой как есть, но вот хвастатся таким стандартом я бы не стал.
> я не знаю по какой причине стандарт такой как есть, но вот хвастатся таким стандартом я бы не стал.То есть, "не читал, но осуждаю".
Он есть. В отличии от.
И он рассчитан на развитие железа и его изменения.
В отличии от некоторых.
Где здесь причина не гордиться им?
Не мычи, ядро по стандарту собрал или нет?
Если нет, то пошол вон.
Это вендорлок.
> и про болт на стандартыЗабавно слышать от фанатов rust'а.
У которых нет стандарта.
И есть 1.2 реализации.
Причем начало второй реализации полностью без проверок.
И спокойно можно писать на этой реализации rust программу. Стандарта то нет.
ха, чем такие стандарты в которых UB в перемешку с implementation-defined, котоые по сути, не гарантирут елементарного! Как сложить два числа без UB !!!уж лучше жить на RFC и не смешить людей такими стандартами.
> уж лучше жить на RFC и не смешить людей такими стандартами.Во! Во! Это ниша пионерских язычков.
Вот так и живите дальше.
> Вот так и живите дальше.А мы будем и дальше "просто брать, и делать UB", да? Ох и цирк...
Это чувство самосохранения.Не заниматься однодневками.
С таким подходом тебе надо безопасненько на Яве писать , или вообще на коболе.Ты не достоин быть частью семьи где отцы основатели сделали язык под проект.
Скопипащу с форума одного сайта. Это то, что очевидно, но как-то многие делают вид, что вообще не понимают, о чем речь, почему-то.
> Что такое вообще код?
> Это реализация,выражение какой-то идеи, записанное в виде набора инструкций. Вопрос же про сопровождение, т.е реализация должна жить максимально долго с минимумом усилий.
> Что может этому помешать? Изменение среды выполнения: ОС, железо, библиотеки.
> Как снизить влияние среды?
> Варианта всего два: либо свой рантайм либо абстрагирование на уровне кода - чтобы везде и всегда собиралось.
> Первый вариант это то что реализуют Java и .NET, второй это Си.Копипасту немного порезал. Там дальше rust ругает.
>> ... чтобы везде и всегда собиралось.блииин, а я всегда думал надо чтоб собранное работало ....
а оно вот как, собралось и ладненько
> блииин, а я всегда думал надо чтоб собранное работало ....
> а оно вот как, собралось и ладненькоЗачем попросту ерничать?
Понятно же, что и работать должно.
> Ну так по этому определению твой любимый пионерский язычок, в котором якобы
> нет UB, может либо запаниковать, либо не запаниковать при переполнении.Не совсем. Это ты можешь либо эт-самое в лужу, либо просто в сторону "растоманов" - в зависимости от настроения и желаний левой пятки. А тут
https://doc.rust-lang.org/std/primitive.u32.html#method.wrap...
> Wrapping (modular) addition. Computes self + rhs, wrapping around at the boundary of the type.все, как хочет погроммист, вне зависимости от опций и языковых расширений компилятора
> ты просто берёшь и делаешь UBАхаха! Чел, ты это серьезно?
Вот и все, что нужно знать о противниках Раста. Зато уже ведь всех окрестил неофитами и пионерами...
> Пионеры не в состоянии понять, что UB - это следствие разнородности аппаратных платформ, с которыми C++ должен уметь эффективно работать непосредственноИзвини, но нет: концепция UB не добавляет C/C++ возможность поддержки каких-то дополнительных платформ, и уж точно она не про эффективность. Согласно стандарту, наличие UB в программе делает ее некорректной на абсолютно любой платформе.
Да он не про "Концепцию Неопределённого поведения" говорит.
Вы явно путаете undefined behavior и implementation-defined behavior. Это _очень_ разные вещи.
Нет, это вы не понимаете, что аппаратная платформа отличается от компилятора, для которого и применяется термин "implementation-defined", и что для аппаратной платформы поведение может быть четко определено даже если оно не определено в стандарте языка.
Ну как бы да, это и есть implementation-defined behavior. Но вы его путаете с undefined behavior, которое при любом раскладе undefined.
> Ну как бы да, это и есть implementation-defined behavior. Но вы его
> путаете с undefined behavior, которое при любом раскладе undefined.Из одного может получиться другое. Скажем формат signed - implementation defined. Откуда вытекает что signed overflow - UB, потому что может быть что так что сяк. В зависимости от формата хранения.
Я ничего не путаю. Это ты не понимаешь, что есть стандарт C++ для десятков компиляторов и сотен аппаратных платформ, в котором есть свои области определения, а есть компиляторы и платформы, которые эти области определения расширяют. То, что что-то не определено по стандарту ISO не означает, что оно не определено по спецификации GCC/Clang и/или AMD. А ты это сравниваешь с пионерским язычком, у которого вообще никакого стандарта нет и есть полторы реализации компиляторов. С точки зрения стандартов весь rust и любая программа на нём - UB.
ага, ага.
стандарт есть, но мягкий 🤣да и сам язычек такой, что при первой возможности бегут с него проекты.
Ты имеешь ввиду мозилу, которая получив опыт, свалила с rust'а?
мозила свалила с раста только в альтернативной реальности местных икспертов.
> Ты имеешь ввиду мозилу, которая получив опыт, свалила с rust'а?Ты нагло лжешь.
https://wiki.mozilla.org/Oxidation#Rust_Components
https://4e6.github.io/firefox-lang-stats/
Так, интереса ради, что на нем сейчас пишут в firefox?Что подсмотреть за интересными примерами?
Бла бла бла UB, бла бла бла implementation-defined ...Так и что там с корректностью?
Один спрыгивает с дырявости на корректность, другой с корректности на неопределенное поведение. Что значит по сути предьяв и сказать нечего. Остаётся только извивается.
> Так и что там с корректностью?
> Что значит по сути предьяв и сказать нечего. Остаётся только извивается.С корректностью чего именно? По сути каких именно предьяв?
>С корректностью чего именно?вот уж действительно, о какой корректности в контексте полюсов можно говорить.
очевидно что у Бьярна начался старческий маразм.
> Бла бла бла UB, бла бла бла implementation-defined ...
> Так и что там с корректностью?Чел, при наличии UB в коде и сам код, и получающиеся из него бинари некорректны по определению. Какое "бла бла бла"?
> Пионеры не в состоянии понять, что UB - это следствие разнородности аппаратных
> платформ, с которыми C++ должен уметь эффективно работать непосредственно.На практике это скорее ведет к хреновой куче багов в коде на ровном месте. А компилер так то имеет право обрубить что угодно до чего угодно оптимизером - если иллюзия не разваливается.
Поэтому код для "int" и "uint16_t" де факто получается как правило одинаковый. Однако есть разница: если вы удумаете назначить что-то явно левое, типа 100500 в uint16_t - вы таки можете варнинг поиметь, а вон там оно спокойно вкатится - чего доброго заюзается как индекс массива какого, на самом деле это опечаточка вышла - но по чужой памяти покатались знатно. И спасибо если не послали ее в сеть или куда там и еще более спасибо если не вкатили это из сети ничего не подозревавшей программе фиг знает куда вообще.
А скажите - вы и правда хотели вот именно "int" как индекс массива? Пока единственный профит который я вижу - возможность влепить отрицательные значения без особого намека на варнинги.
Более того - это даже до олдов дошло. До тех которые нормальные. Читать Торвальдса в пуллреквестах bcachefs до просветления. Там где про bit fields vs enum. И это все - вот как раз поэтому. Там Торвальдс мастеркласс по антибагу до кучи дал. Его то жизнь заставила. А кентушка створил какую-то хрень, запостив pull с явным багом и довольно крутым. А старого лиса вот не проведешь - баги за версту чует.
> Страуструп тут недавно выступал и совершенно точно подметил, что те, кто думает, что корректность программы исчерпывается правильной работой с памятью, не понимают примерно ничего в этой жизниДа, да... А то, что более 70% всех уязвимостей в софте вызваны именно неправильной работой с памятью в C и C++ он тактично промолчал?
Нет, ровно об этом и говорил: do not use low-level unsafe features - hide them in containers or libraries.
> hide themАга, уязвимости же от этого магическим образом исчезают. Это типа как мусор заметать под ковер. Как жаль, что всякие дурачки, изабретающие и внедряющие расты, не знают об этом простом и эффективном способе решения 70% проблем.
ну не может же он сказать "мое детище это кусок кала, мы забивали на безопасность, логику и здравый смысл"
Ну и где у нас нормальные компиляторы?-))
Лучше valgrind'а?
одновременно юзаю valgrind, clang static analyzer и cppcheck
> Лучше valgrind'а?Он как бы не замена оному. Есть статический анализ, а есть анализ в рантайме. Valgrind о втором. Он рантайм-анализатор проблем и его больше смысла сравнивать с asan/ubsan чтоли. Которые так то тоже не замена статическому анализу а рантайм-дополнение к нему.
Чего только не придумают лишь бы не писать без ошибок...
Действительно, ведь всего-то нужно начать сint main(void)
{
return 0;
}а дальше — согласно стандарту. Изи.
я бы еще добавил каст к void*, ну так, чисто чтобы держать планку
и чтобы следующие пограммисты не расслаблялись)
согласно теории ошибок либо у тебя в программе нет ошибок, либо она никому не нужна
*есть ошибки
Кто-то хоть раз с этим анализатором РЕАЛЬНЫЙ баг находил? вот который на самом деле происходит, а не так, "теоретически, если потом кто-то поменяет код".По мне эти улититы анализа - пустая трата времени на то чтобы читать их высеры
Да, например случайная копипаста недоправленная, т.е. что-то типа (точно не помню):
memcpy(x, y, sizeof(y));
memcpy(z, k, sizeof(y));
> Да, например случайная копипаста недоправленная, т.е. что-то типа (точно не помню):
> memcpy(x, y, sizeof(y));
> memcpy(z, k, sizeof(y));Можно рубануть в стиле антибаг. Наример:
#define MEMCOPY(x, y) memcpy((x), (y), sizeof(y))....а теперь попробуйте так облажаться в MEMCOPY() вообще? Да, caveats у этого решения увы, тоже есть :). А еще в идеале нехило бы проверить что sizeof(x) == sizeof(y). Иначе можно жизнерадостно вынести все что за x из памяти и глазом не моргнуть если x меньше y по размеру.
Эти олдовые функции мало того что с дурным прототипом так еще злее опасной бритвы. В два счета снимут скальп случайно при бритье, если заказать что-то не то. И вот идете вы такой весь перемотаный бинтами на горле, черепухе, "ничего себе к цирюльнику сходил"
> статического анализатора кода для языков C++ и СА почему не С и С++? Так же намного привычнее.
ну, наверно, потому что это cpp check, а не c check +).
хорошая штука, до VPS 🦄 конечно не дотягивает, но всё же.
А существует ли книга (или серия статей) о best practices в языке C? Чтоб сразу писать более надежно, а не набивать шишки.
> А существует ли книга (или серия статей) о best practices в языке
> C? Чтоб сразу писать более надежно, а не набивать шишки.1. Embedded C coding standard - by M.Barr - можно укачать нашару насколько я помню.
2. Правила MISRA C. Сие легально на шару укачать низя, увы - проприетарщики. Но найти можно если нужно.
3. Почитать блог Cyan (автора LZ4) на тему этого самого. Там есть здравые идеи.
4. Забить в поискарь "antibug coding C" и получить бонусов из разных мест. Узнаете почему лучше сравнения делать вида if (10 == a) а не (if a == 10). Хинт: при опечатке if (a = 10) vs if (10 = a) это две большие разницы. Поэтому второй вариант - антибажный.
5. Посмотреть на практикующих гуру. Жесткую эмбедоску, линукскернел, все такое. Получите немало идей как не стрелять себе в пятки. От макро ARRAY_SIZE какой до авто-вычисления масок для битовых полей вместо того чтобы телепаться самому. Можно даже с проверкой что биты влезли в энную ширину.Это может быть оверкиллом - но получив знание можно дальше уже по ситуации смотреть насколько оно имеет смысл в конкретном случае. Скажем правила MISRA довольно жесткие и не сказать что удобные. Но они имеют под собой определенный пойнт.
> 4. Забить в поискарь "antibug coding C" и получить бонусов из разных мест. Узнаете почему лучше сравнения делать вида if (10 == a) а не (if a == 10). Хинт: при опечатке if (a = 10) vs if (10 = a) это две большие разницы. Поэтому второй вариант - антибажный.И есть несколько книг, описывающие, что так делать нельзя, так как хуже воспринимается человеком. А код должен понимать человек. И написан он должен быть так, что бы его было легче воспринимать.
А такие ошибки уже давно не то что cppcheck'ами проверятся, а самими компиляторами.
> И есть несколько книг, описывающие, что так делать нельзя, так как хуже
> воспринимается человеком.Компилер при случае жестко рубанувший присвоение переменной a числу 10 как невозможное деяние - очень сильно перевешивает эти соображения. На мой вкус выглядит почти однофигственно на самом деле. А вот опечататься случайно в синтаксически-валидном виде - в вон том характерном стиле не получится уже принципиально. Потому и часть идей antibug.
> А код должен понимать человек. И написан он должен быть так, что бы его было
> легче воспринимать.Как показала практика, одно другому не мешает - зато гасит баги из-за typo на подлете. И если вы хотите холодный душ, у хрустиков вот жто вот - антибажнее. Хоть я и не понимаю чем им := вместо let mut blablabla не зашел, но все же, до идеи явной демаркации присвоения они доперли.
> А такие ошибки уже давно не то что cppcheck'ами проверятся, а самими компиляторами.
Это в случае компилера как самый максимум варнинг а не еррор. И то зависит от. А анализатор это вообще страховочный трос, он не для того чтобы на нем постоянно отвисать.
А вот при присвоении числу переменной компилер это совершенно точно загасит. И логически условие вообще совсем никак от этого не меняется. А что справа и что слева в общем то чистая вкусовщина, на логику условия не влияет же.
>при опечатке if (a = 10) vs if (10 = a)Никогда не понимал, почему в сишке разрешено присваивание в условии. Ведь это ещё один источник ошибок.
if( a ) .. - не смущает же
и if( retcode=fn() ) .. тоже не смущает, и более того, всё очевидноА вот if( a = b ) - уже нарушает читаемость, и чужого не работающего кода особенно, ибо возникает подозрение на опечатку.
Ну а if( a = const ) - это с вероятностью 96% - ляп.
В оставшихся случаях это последствия автогенерации кода, или замены #ifdef на константные if.
Честно говоря - смущает.
> и if( retcode=fn() ) .. тоже не смущает, и более того, всё очевидноВопрос: а зачем тут "retcode" вообще? if ( fn() ) было чем-то не круто? Или если retcode надо потом то зачем это в if () вообще было? Чтобы логику менее очевидной сделать?
например, для того, чтобы
if ((retcode = fn()) == 0)
{
}
else
if (retcode > 0)
{
}
else
{
}
Чувак, открой для себя тег [!code] ... [!/code] (без восклицательных знаков, они тут для срыва парсинга этого тега). Хотя возможно ты получившимся контринтуитивным форматированием где мозг сломаешь какая ветка в каком случае выполняется специально вкатил и хотел подхайлайтить лишний раз почему так программить не стоит? :)
Сэкономить одну строчку на кулхацкерских понтах
> Сэкономить одну строчку на кулхацкерских понтахКак-то так в программах и появляются баги на ровном месте, а коллега неверно трактовавщий фрагмент кода - наломает и еще дров.
https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1
Вот здесь список проявлений неопределённого поведения.