Текущая команда пока не планирует особо сильно менять Geany, потихоньку исправляют ошибки, не более того. Единственное, что возможно действительно серьёзное появится — это интеграция с clang, но вот устранять архитектурные проблемы никто не будет. Основные изменения в настоящий момент вносятся внешними разработчиками.
Ошибка одна, но контекст её возникновения обычно неоднозначен. Та же утечка памяти — банальная и распространённая ошибка. Тем не менее условия, в которых она возникает — безграничны.
Пиар, конечно, это не отменяет, но с другой стороны, очередному проекту Х придётся призадуматься о качестве кода, что хоть немного сделает мир лучше.
А для этого вообще и придумали strcmp, функция безопасная, тем более для «внутренних данных». Я понимаю ещё если строка приходила из враждебной среды да без проверок. Тут просто явно ставилась задача сравнить первые несколько символов. Для наглядности можно даже так написать:
strncmp(var->fexternal, "cintfx", strlen("xxxx"))
Всегда приятно видеть код который говорит за себя. Например:
Локальная переменная точно будет оптимизирована, что касается глобальный — режим параноика как правило касается указателей. В общем случае, указатели даже могут пересекать одну и ту же область памяти и компилятор вынужден предполагает наихудшие сценарии. А вообще см. коммент ниже — я давно не видел хороших статей про оптимизирующие компиляторы — всё анализаторы да анализаторы… Понятно, что все пишут плохой код, вопрос в том как писать хороший:)
Возможно и не сталкивались — большинство редакторов на Scintilla (тот же Notepad++, о котором я могу более-менее судить) не претендуют на функциональность IDE и автодополнения символов а-ля Eclipse там нет. Единственный блокнот, где есть нормальное автодополнение — Sublime, но там похоже всё самописное. Учитывая примитивную реализацию вряд ли разработчики столкнулись с проблемами (считал введеный символ, записал парный — такой плагин в строк 15 уместится). Я могу гарантировать что патч, затрагивающий код Scintilla, не примут, а пропихивание сразу двух патчей в два не связанных друг с другом проекта в мои временные лимиты просто не укладывается. В Geany и так слишком консервативная разработка и даже багфиксы ждут своего часа годами.
> сильно не нравится то, что горизонтальный скроллинг не учитывает реальное состояние
Как там сказано, это for performance reasons. Я обычно всегда использую перенос строк и этот скроллбар не так уж и мешает. Но я не разработчик Scintilla и даже не контрибьютор, разбираться с компонентом редактирования желания не было — как раз производительность Scintilla даёт изюминку Geany:) В Geany ML были поползновения в сторону другого компонента редактирования — GtkSourceview, но на мой взгляд его производительность значительно отстаёт, хотя он и более OpenSource-вейный.
Отказываются исправлять опять же не просто так: Geany зависит от кодовой базы Scintilla и использует её непосредственно внутри себя. Т.е. если разработчики начнут ковырять движок Scintilla, им придётся потом заниматься его поддержкой. Учитывая что автор Geany перестал им заниматься, у текущей команды из двух с половиной человек нет просто на это ресурсов.
Нет, не пытался даже. Я планировал отслеживать нажатия определённых клавиш, включая Shift и Backspace, а в API предусмотрена лишь передача кодов введенных символов, т.е. ни Shift, ни Backspace тут уже не вписываются, так как это клавиши, а не символы. Там предусмотрено событие DELETE, то есть удаление символа, но оно опять же не позволяет узнать какое это удаление — то ли Delete, то ли Backspace что в случае этого плагина было важно. То есть требования очень специфические, но ради небольшого плагина переделывать API движка, который используется в десятках редакторов — я думаю это перебор:)
for (ifoo = 1; ifoo < ifooMac; ifoo++);
{
if (*pvoteFoo == 0)
goto LRet;
if (*pvoteFoo > voteMaj)
{
fooMaj = *pfoo;
voteMaj = *pvoteFoo;
}
*pfoo++;
*pvoteFoo++;
}
Где-то четверть кода написана на ассемблере, остальное — чистый си, в общем даже достаточно аккуратный си. Ждём поста про то как PVS-Studio чихвостит Microsoft:)
Прошу прощения что мой вопрос не про политику. А как же электроэнергия? Цены на энергию у нас в состоянии погубить любой бизнес в зародыше. На офф. сайте даже потребляемая мощность не указана — сколько такой экструдер потребляет электричества 24/7? Также извольте платить за отопление, освещение и т.п. — это много больше даже чем расходники. У нас в отличие от Китая ещё и крепкие морозы бывают.
Результаты есть, но я пока их не обрабатывал. Сейчас будет понятно почему. Я проверял старый как бивень мамонта Xorg, версия, когда ещё вашего анализатора и знать не знали. Ошибок в нём оказалось столько, что хромиум, source sdk, и cryengine даже вместе взятые отдыхают. 1791 ошибок нашёл PVS (сначала было 20 тысяч, но всё-таки я как-то отфильтровал, много предупреждений было из-за препроцессора и несовместимости с Linux) и cppcheck — 2801. Это намного больше, чем то, что описано здесь.
Собственно, какой уровень ошибок поставили — такой результат и получили:) И это несмотря на то что я недавно писал, что в cppcheck нет уровней, все ошибки важны, они просто разбиты на категории, а категория error — это баги, в которых анализатор уверен на 100%. По моим тестам cppcheck и CppCat при включении всех предупреждений выдают равное кол-во ошибок.
В предыдущем сравнении хотя бы приводилась корреляция ошибок.
Особенно легко и непринуждённо VS запускается в RHEL.
Если статья об анализе ключевой библиотеки Linux, вы привлекли внимание всех читателей хаба Linux — извольте приоткрыть тайну анализа линуксовых библиотек. Сейчас из поста получается «раз! — и результат» — это-то и сбивает с толку людей. А процесс копания в настройках компилятора/препроцессора, а также ковыряние километрового лога остался за кадром. Было бы интересно читать как вы решали эти проблемы, а не как тяжело писать код под Linux.
Риски выше, как уже правильно выше сказали — за бекапы данных клиента отвечаете теперь вы лично, а не хостер, нужно следить за серверами, аптайм, обновления, пиковая нагрузка, мониторинг и техподдержка и т. п. Я всецело за виртуализацию, но нужно ещё развивать культуру администрирования Linux в России, а с этим у нас пока туговато. Стоимость VPS как бы подоспела, а вот клиенты и администраторы не все к этому готовы: кому-то некогда, кому-то лень, кому-то не хватит знаний. Обучение MS Paint в школах и MS Word в университетах особенно способствует этому.
Иногда гнать весь код через препроцессор компилятора не самое удачное решение. Именно как раз потому, что это implementation-defined, зависит от используемого компилятора/ОС и не позволяет вычислять ошибки совместимости. Но есть хорошие новости: можно задать параметр оптимизации -O0, когда никаких «левых» inline-подстановок компилятора не возникнет.
Для меня стало открытием наличие такого бреда в препроцессоре. В ассемблерном варианте окажется что-то вроде этого:
Пиар, конечно, это не отменяет, но с другой стороны, очередному проекту Х придётся призадуматься о качестве кода, что хоть немного сделает мир лучше.
Всегда приятно видеть код который говорит за себя. Например:
Хотя ваш анализатор не проверяет утечки памяти, прочувствуйте гордость за своего подопечного:
> сильно не нравится то, что горизонтальный скроллинг не учитывает реальное состояние
Как там сказано, это for performance reasons. Я обычно всегда использую перенос строк и этот скроллбар не так уж и мешает. Но я не разработчик Scintilla и даже не контрибьютор, разбираться с компонентом редактирования желания не было — как раз производительность Scintilla даёт изюминку Geany:) В Geany ML были поползновения в сторону другого компонента редактирования — GtkSourceview, но на мой взгляд его производительность значительно отстаёт, хотя он и более OpenSource-вейный.
Отказываются исправлять опять же не просто так: Geany зависит от кодовой базы Scintilla и использует её непосредственно внутри себя. Т.е. если разработчики начнут ковырять движок Scintilla, им придётся потом заниматься его поддержкой. Учитывая что автор Geany перестал им заниматься, у текущей команды из двух с половиной человек нет просто на это ресурсов.
И коричневый пояс по пустым циклам:
Где-то четверть кода написана на ассемблере, остальное — чистый си, в общем даже достаточно аккуратный си. Ждём поста про то как PVS-Studio чихвостит Microsoft:)
В итоге:
— Cat — включено 100% предупреждений
— PVS — включено 70% предупреждений
— Cppcheck — включено 30% предупреждений
Собственно, какой уровень ошибок поставили — такой результат и получили:) И это несмотря на то что я недавно писал, что в cppcheck нет уровней, все ошибки важны, они просто разбиты на категории, а категория error — это баги, в которых анализатор уверен на 100%. По моим тестам cppcheck и CppCat при включении всех предупреждений выдают равное кол-во ошибок.
В предыдущем сравнении хотя бы приводилась корреляция ошибок.
руиныдетище этого универа: www.ssl.stu.neva.ru/fenix/index.htmlПрямо как в музее побывал.
Особенно легко и непринуждённо VS запускается в RHEL.
Если статья об анализе ключевой библиотеки Linux, вы привлекли внимание всех читателей хаба Linux — извольте приоткрыть тайну анализа линуксовых библиотек. Сейчас из поста получается «раз! — и результат» — это-то и сбивает с толку людей. А процесс копания в настройках компилятора/препроцессора, а также ковыряние километрового лога остался за кадром. Было бы интересно читать как вы решали эти проблемы, а не как тяжело писать код под Linux.
Причём, модули C/C++ — коммерческие, если я правильно понял это: docs.codehaus.org/display/SONAR/Plugin+Library
А такие «Богом забытые» языки как С++ и С поддерживает? Просто из поста совершенно непонятно.
Иногда гнать весь код через препроцессор компилятора не самое удачное решение. Именно как раз потому, что это implementation-defined, зависит от используемого компилятора/ОС и не позволяет вычислять ошибки совместимости. Но есть хорошие новости: можно задать параметр оптимизации -O0, когда никаких «левых» inline-подстановок компилятора не возникнет.
Для меня стало открытием наличие такого бреда в препроцессоре. В ассемблерном варианте окажется что-то вроде этого: