Comments 37
Хоть в целом я полностью согласен с тем, что регулярки для полноценного анализа — инструмент никоим образом не подходящий, всё же нельзя не отметить, что возможность расширять анализ собственными правилами, построенными на регулярках, всё же могут оказаться полезны. Возьмём такой элементарный фантастический пример: пусть ни компилятор, ни PVS не обнаруживают опечатку вида if (a = b), и пользователь хочет добавить её распознавание сам. Если в PVS были бы регулярки, он бы запросто написал такое правило:
PS: Отдельно стоит вопрос о ложных срабатываниях внутри строк и комментариев, но тут уже не должно быть проблемой заставить PVS при прогоне пользовательских регулярок подсовывать им только реальный код. Если другие правила хотят анализировать строки, то можно добавить опции, говорящие, какие структуры включать в анализ данным конкретным правилом, а какие — нет.
if\s*\(\w+\s*=\s*\w+\)PS: Отдельно стоит вопрос о ложных срабатываниях внутри строк и комментариев, но тут уже не должно быть проблемой заставить PVS при прогоне пользовательских регулярок подсовывать им только реальный код. Если другие правила хотят анализировать строки, то можно добавить опции, говорящие, какие структуры включать в анализ данным конкретным правилом, а какие — нет.
С ветряными мельницами бороться бесполезно, а заблуждение, что разобрать нерегулярный текст можно с помощью регулярных выражений, является как раз такой мельницей. Корни этого заблуждения очень просты:
Кстати, funboy регулярных выражений может запросто с вами спорить, логика тут бесполезна. Их излюбленные способы: апелляция к слухам («я слышал, что в Perl регулярные выражения настолько мощные, что там это возможно „) и “добавить чуть-чуть кода». Под добавлением чуть-чуть кода они имеют ввиду создание парсера вручную поверх частично разобранных регулярными выражениями фрагментами текста (по сути, регулярки используются только как часть лексера).
- регулярные выражения встроены как DSL практически в каждый язык программирования (порог входа явно ниже, чем, например, у yacc)
- регулярные выражения кажутся сложными, поэтому, их применение ко всему подряд, дает автору +1 к ЧСВ
Кстати, funboy регулярных выражений может запросто с вами спорить, логика тут бесполезна. Их излюбленные способы: апелляция к слухам («я слышал, что в Perl регулярные выражения настолько мощные, что там это возможно „) и “добавить чуть-чуть кода». Под добавлением чуть-чуть кода они имеют ввиду создание парсера вручную поверх частично разобранных регулярными выражениями фрагментами текста (по сути, регулярки используются только как часть лексера).
Что-то мне подсказывает, что сделать нормальный анализатор можно лишь на Тьюринг полном языке программирования. А я что-то не слышал, чтобы регулярки у нас вдруг стали Тьюринг полными.
И тем не менее, возвращаясь к возможности написания своих правил, думаю при такой продуманной архитектуре, как у вас, можно реализовать механизм подключения плагинов с собственными правилами.
> Те, кто знаком с теорией компиляции, конечно же понимают, что язык Си++ можно разбирать только на основе грамматик, а не регулярных выражений.
Существует мнение что даже просто грамматик не достаточно: users.livejournal.com/_winnie/13725.html
Существует мнение что даже просто грамматик не достаточно: users.livejournal.com/_winnie/13725.html
Насколько было проще, если бы все программисты дружили с лингвистами :)
ru.wikipedia.org/wiki/Иерархия_Хомского
ru.wikipedia.org/wiki/Иерархия_Хомского
Лично мне кажется что это вообще must know. Для любого программиста, даже прикладника. И старперское брюзжание что «каждый программист должен написать свой ЯП и свою ОС» мне не кажется столь безосновательным.
В первую очередь потому, что банальнейший парсер, писанный руками, мгновенно открывает глаза разные вещи. Например то, что if не всесилен. И не любую программу можно «чуток подкрутить».
Когда человек начинает сталкиваться с ситуацией, что добавить «еще одну запятую» с точки зрения функциональности может вылиться в 3 страницы кода… то после таких граблей невольно начнешь думать как сразу сделать по уму. Вне зависимости от текущей задачи. Просто при написании парсеров это проявляется наиболее полно и быстро :)
В первую очередь потому, что банальнейший парсер, писанный руками, мгновенно открывает глаза разные вещи. Например то, что if не всесилен. И не любую программу можно «чуток подкрутить».
Когда человек начинает сталкиваться с ситуацией, что добавить «еще одну запятую» с точки зрения функциональности может вылиться в 3 страницы кода… то после таких граблей невольно начнешь думать как сразу сделать по уму. Вне зависимости от текущей задачи. Просто при написании парсеров это проявляется наиболее полно и быстро :)
Абсолютно согласен. Кажется, попытка иронизировать была в очередной раз столь тонкой, что умерла от истощения. My bad.
Я это к тому, на само деле, что ответ на вопрос «а почему не регулярные выражения» должен быть коротким: «потому что грамматика С/С++ контекстно-зависима». Если этого спрашивающему недостаточно, то нужно решать проблему пробелов в знаниях куда более фундаментальную, чем задано вопросом.
И тема, на самом деле, страшная. Тем, что в ней возникает необходимость. Это я как человек-без-образования-у-которого-молоко-на-губах-обсохло™ говорю :(
Я это к тому, на само деле, что ответ на вопрос «а почему не регулярные выражения» должен быть коротким: «потому что грамматика С/С++ контекстно-зависима». Если этого спрашивающему недостаточно, то нужно решать проблему пробелов в знаниях куда более фундаментальную, чем задано вопросом.
И тема, на самом деле, страшная. Тем, что в ней возникает необходимость. Это я как человек-без-образования-у-которого-молоко-на-губах-обсохло™ говорю :(
Вообще говоря любой программист с академическим образованием (читай: не самоучка) обязан это знать, потому как Теория Языков Программирования, в которую все это входит, в университетах преподается. И стало быть будущих программистов которые этот курс не освоили, выпускать из университета можно только вперед ногами, но это в идеале, а мы к сожалению в реальной жизни.
Есть ли планы на создание такого рода анализатора для linux? Консольная тулза была бы очень кстати.
Консольная тулза уже есть.
У меня возникает ощущение, что если вы выделите ядро системы в библиотеку (что-то мне подсказывает, что так и есть), компилируемую под линуксом, и выложите исходники GUI и CLI интерфейсов, то найдутся энтузиасты, которые их сами перепишут :-)
Сто тысяч лет наша библиотека VivaCore (http://www.viva64.com/ru/vivacore-library/) является открытым опубликованным проектом с исходниками.
Понимаю, что вас уже достали за последние сутки :-) Да, я её видел, потому и предположил такую возможность. Вот если бы вы распространяли набор правил общего назначения не только как часть PVS-Studio в виде установщика для Win, но и как библиотеку (в том числе для nix)…
>> Понимаю, что вас уже достали за последние сутки
Ни-чё, работа такая…
>> Вот если бы вы
И что бы изменилось? :-)
Ни-чё, работа такая…
>> Вот если бы вы
И что бы изменилось? :-)
Тогда интерфейс к ним мог бы реализовать кто-то заинтересованный в этом продукте под linux.
И сколько людей из кричащих на форумах умеют что-то делать? :-)
Я в этом (ой, нет, в соседнем, но Вы его легко найдете) топике уже писал, что скомпилировать exe-шник и выпустить программный продукт определенного качества — это разные действия.
Я в этом (ой, нет, в соседнем, но Вы его легко найдете) топике уже писал, что скомпилировать exe-шник и выпустить программный продукт определенного качества — это разные действия.
Мало, но по крайней мере это не даст им повода задавать глупые вопросы из соседнего топика.
Прочитал ветку про качество, чтож, понимаю. Видимо не стоит ожидать от вас linux-версии библиотек в ближайшее время :-(
Прочитал ветку про качество, чтож, понимаю. Видимо не стоит ожидать от вас linux-версии библиотек в ближайшее время :-(
>> Мало, но по крайней мере это не даст им повода задавать глупые вопросы из соседнего топика.
Да пусть задают. Просто дома софт никто не пишет (ой) для Линукса. Его пишут в рабочее время и за это платит работодатель. А работодателю лучше нам заплатить и мы все сделаем в лучшем виде.
>> Видимо не стоит ожидать от вас linux-версии библиотек в ближайшее время :-(
Отчего же, поучавствуйте финансово в разработке — будет linux-версия.
Да пусть задают. Просто дома софт никто не пишет (ой) для Линукса. Его пишут в рабочее время и за это платит работодатель. А работодателю лучше нам заплатить и мы все сделаем в лучшем виде.
>> Видимо не стоит ожидать от вас linux-версии библиотек в ближайшее время :-(
Отчего же, поучавствуйте финансово в разработке — будет linux-версия.
На тему PVS-Studio Standalone и Linux, возможно будет интересна вот эта новая заметка — "PVS-Studio теперь работает и без среды Visual Studio или C++Builder – проверяем препроцессированные файлы от чего угодно".
Свершилось: PVS-Studio для Linux.
Я рад прежде всего что российский стартап, из города Тулы стал таким… Мощным старапом! Очень хочется чтобы основной офис так и остался бы в Туле, чтобы другие города смотря на это, также не стесняясь выдавали сверхпродукты :)
Рапортую о проблеме. Раньше свой проект я компилировал gcc, ради Вашего анализатора я убил несколько часов и теперь проект на ура компилируется студией (отдельное спасибо, наконец заставил себя сделать это). Тем не менее запуск анализатора (PVS-Studio->Check Solution) ничего не дает. Мой проект использует Qt, в логах анализатора я вижу только:
Всего 269 ошибок о том что невозможно открыть файл относящейся к сырцам Qt (мне не понятно зачем это) и больше никакой ошибки или предупреждения. Беглый осмотр настроек PVS не выявил возможности задать/отключить инклюды. Возможно я не попадаю под use case. Внесите ясность ;)
02 ../SomeFile.h(11): fatal error C1083: Cannot open include file: 'QWidget': No such file or directory moc_SomeFile.cpp 1 False
Всего 269 ошибок о том что невозможно открыть файл относящейся к сырцам Qt (мне не понятно зачем это) и больше никакой ошибки или предупреждения. Беглый осмотр настроек PVS не выявил возможности задать/отключить инклюды. Возможно я не попадаю под use case. Внесите ясность ;)
Для того, чтобы выполнить анализ кода, необходимо сначала осуществить препроцессирование — раскрыть все инклуды и дефайны. Это мы делаем препроцессором от Visual C++ (который есть часть cl.exe). Ошибку выдает именно препроцессор — он не может найти заголовочный файл QWidget. Странно, что при этом проект компилируется студией.
Тем не менее проверьте, добавлен ли путь до заголовков Qt в Additional Include Directories в настройках проекта или настройках Visual C++ (см. VC++ Directories в настройках Visual C++).
Если не заработает, скажите — будем разбираться, что еще могло быть не так.
Тем не менее проверьте, добавлен ли путь до заголовков Qt в Additional Include Directories в настройках проекта или настройках Visual C++ (см. VC++ Directories в настройках Visual C++).
Если не заработает, скажите — будем разбираться, что еще могло быть не так.
Не заработало. Я прописал в VC++ Directories C:\Qt\src\include. В сообщениях об ошибках он пишет что не может обнаружить файл QWidget или QObject. Но ведь это не совсем верно, инклюд в исходниках выглядит так #include или #include . Т.е. на самом деле QWidget это не файл, он должен ссылаться например на QtGui\QWidget.h который естественно есть в C:\Qt\src\include\QtGui\QWidget.h. Мне кажется в этом проблема. С новыми изменениями студия по прежнему успешно компилит проект. Будет свободное время — попробую на qt example запустить анализатор, может все же у меня проблема.
Поищите поиском файл QWidget (именно так, без ".h") и сделайте «включение» той папки. Явно проблема в том, что не включена она в include directories. Но VS почему-то видит, а PVS-Studio — нет. Возможно какие-то специальные переменные окружения QT используются, которые мы игнорируем.
Вы были правы, после добавления полных путей (к каждой под паке из папки include) все завелось. Запустил жду эффекта, уже парочка варнингов есть. Спасибо Вам.
Опишите потом здесь свои впечатления, пожалуйста.
Анализ займет некоторую часть времени неделю наверное. По результатам отпишусь либо сюда, либо статью создам (правда боюсь заминусуют).
Анализ занял (непосредственно анализ PVS) 3 часа. Было выявлено 120 — Level 1 Warning, 159 — Level 2, 280 — Level 3. Многие ошибки повторяются — одна и та же ошибка расслаивается на несколько строчек (т.е. ошибка одна, но в логе выдается что их несколько). Анализировать очень сложно из-за триальности нет навигации по коду, конкретное место ошибки не подсвечивается. В Level 3 Warning львиная доля V001 ошибок — не возможно анализировать исходник.
Напишите что Вам особенно интересно от меня, постараюсь учесть в своем отчете.
Анализ занял (непосредственно анализ PVS) 3 часа. Было выявлено 120 — Level 1 Warning, 159 — Level 2, 280 — Level 3. Многие ошибки повторяются — одна и та же ошибка расслаивается на несколько строчек (т.е. ошибка одна, но в логе выдается что их несколько). Анализировать очень сложно из-за триальности нет навигации по коду, конкретное место ошибки не подсвечивается. В Level 3 Warning львиная доля V001 ошибок — не возможно анализировать исходник.
Напишите что Вам особенно интересно от меня, постараюсь учесть в своем отчете.
>> либо статью создам (правда боюсь заминусуют).
Не бойтесь, мы поддержим плюсиками :-).
>> Анализировать очень сложно из-за триальности.
Сейчас пока еще General Analysis бесплатно. 64-битные ошибки можно выключить просто.
V001 — не страшно, это всего-лишь маленький кусочек кода не разобрался. В основном файл обработан.
>> Напишите что Вам особенно интересно от меня
Чтобы Вы купили. :-)
Не бойтесь, мы поддержим плюсиками :-).
>> Анализировать очень сложно из-за триальности.
Сейчас пока еще General Analysis бесплатно. 64-битные ошибки можно выключить просто.
V001 — не страшно, это всего-лишь маленький кусочек кода не разобрался. В основном файл обработан.
>> Напишите что Вам особенно интересно от меня
Чтобы Вы купили. :-)
Вот мой отчет habrahabr.ru/blogs/cpp/110515/
Sign up to leave a comment.
Статический анализ и регулярные выражения