Pull to refresh

Comments 48

Он скорее на Launchpad.net доступен.
Как вы относитесь к тому что, разработчики не указывают в changelog что PVS-Studio нашел ошибки в их ПО?
UFO just landed and posted this here
А вот это интересный вариант. Может быть потом какие-нибудь корреляции выяснились между качеством кода и предпочитаемым напитком. HR ходили бы в бары хантить персонал.
Можно было бы давать бесплатную версию за рекламу инструмента в чейнджлоге и описании обновлений :-)
А почему
if (!spfont) return // <=

вообще скомпилировалось? Там же void функция, которая не может ничего возвращать.
void функция может вернуть результат другой void функции.
отсутствие результата тоже результат
Однопроходовый цикл while используется вместо кучи if () goto… Согласен, не совсем красивый код, но всяко лучше кучи goto.
Тоже часто пользуюсь подобной идиомой. Можно ещё do {} while(false), если условий нет. Странно, вроде как очень востребованный паттерн, а что-то не припомню ни в одном языке специальной конструкции для него. Например, было бы логично сделать просто do {} с возможностью break.
Как раз думал чем же заменить:
$status = true;

if (1 == 2) {
    $status = false;
}

if ($status) {
    // ...
}

if ($status) {
    // ...
}
Лучше замени на функцию с return. Это более красивое решение.
Да, так и сделал, но это не решает другой проблемы. Предположим, если условие 2
if ($status) {

в случае неудачи должно что-то выполнить, то return не спасает.
Если честно, я вообще не вижу смысла в вашем коде. Так как вторая проверка статуса имеет смысл только внутри первой.
А причем тут вообще while (cond) {… break; }?
Не только. Можно все сделать как вы сказали, но получится вот это:
        if (1) {
            if (2) {
                if (3) {
                    if (4) {
                        if (5) {
                            
                        }
                    }
                }
            }
        }
Понимаю, код не красивый — сам такие конструкции стараюсь избегать. Но зато смысл работы очевидный, в отличие от первого варианта.
Для меня наоборот менее читабельный подобный код, я в таком коде начинаю немного путаться с таким обилием кудрявых скобок и вложенностей.
Зачем больше, если можно меньше?

Вон в Go обходятся одним for на все случаи жизни. Аналогом такой конструкции будет

for {
//…
break
}

Не совсем аналогом: while сначала проверяет условие и заходит в тело только если оно истинно, т.е. ваша конструкция будет выглядеть как-то так:


if cond {
  for {
    // ..
    break
  }
}
Ну это такой же костыль, как while(true) { break;}. Желательна конструкция, в которой не надо будет в конце лишний break делать.

Вы забыли про:


do {

} while (false);

Ставить break в конце не нужно ;-) Но в коде выше тогда потребуется отдельный if (cond) ...

Не забыл, в своём первом комментарии выше я про него написал. Если был бы do{}, то if лучше было бы ставить явно.

А чем break лучше goto? Я понимаю, что используя goto можно писать очень запутанный код, который сложно поддерживать, но тут-то использование абсолютно прозрачно.

С goto могут возникнуть проблемы с созданием переменных. Имхо, лучше выделить в отдельную функцию.
Здравствуйте! Хочу вас спросить: можно ли предложить вам проекты открытого ПО? Или вы проверяете только то, что сами сочтете нужным?
К примеру, было бы очень неплохо проверить Mesa — недавно как раз вышла новая версия.
Мы открыты предложениям. Пишите нам или можете оставлять комментарии здесь. Mesa возьмём на заметку.
Посмотрите еще слои валидации для API Vulkan. Проект сам по себе небольшой, и вещи делает достаточно скучные, но от его качества зависит, по сути, будет ли этой библиотекой кто-то пользоваться.
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers
Самым очевидным решением проблемы является использование блока try {....} catch(const std::bad_alloc &) {....}

Простите за занудство, но самым очевидным решением является замена new на new (std::nothrow). Тогда остальной код менять не надо — разве что бессмысленный delete[] buffer удалить.
то данный метод определенно следует переписать так:

Простите, но нет. Судя по коду автор явно хотел сделать триггер, что если значение back меняется, то только тогда делать ResetPoints(), т.е. код бы получился таким:


void
Path::SetBackData (bool nVal)
{
  if (back != nVal) {
    back = nVal;
    ResetPoints();
  }
}

Как минимум это подтверждается, если проверить случаи когда back == true и nVal == true или back == false и nVal == false — в этих случаях никаких действий код автора выполнять не будет.

Да уж, разобраться в том месиве if и правда сложновато, наверняка, даже написавший её программист боится трогать ту функцию, работает — и слава Богу…

оффтоп
Мне больше нравится в стиле Кармака:

void
Path::SetBackData (bool nVal)
{
  if (back == nVal) return;
    
  back = nVal;
  ResetPoints();
}

разобраться в том месиве if и правда сложновато

Да не очень. Достаточно по контексту или какому-то другому знанию понять — что вообще хотелось, а дальше просто составить табличку и проверить комбинации параметров. Собственно я это и сделал. Скорее всего этот кусок кода был написан на заре проекта, работает (а он действительно работает правильно, хотя и выглядит ужасно) и в него просто никто не смотрит. Я в свои старые проекты тоже без слёз смотреть не могу — растём, учимся.


оффтоп

да, я тоже так делаю в своей практике, правда не знал, что это ещё чей-то стиль :) Но для небольших кусков кода, случается, делаю исключение — если одним взглядом всю функцию видно. Сниппет же выше специально, что бы обратить внимание на триггер.

//TODO: figure out why do we need to append("")
// before clearing items properly...

К вопросу о том, что статический анализ не нужен, потому что "как можно не заметить отсутсвие точки с запятой?!!"

Если писать без автоформатирования, то да, возможно. Я привык часто жать Ctrl+Shift+F, чтобы код выглядел красиво, в этом случае выражение прыгнуло бы к return и стало бы самоочевидно. Ошибка с пропущенной запятой точно так же стала бы заметна.

А ещё я совершенно не понимаю, зачем в проекте на C++ использовать сишные strcmp и memcpy, которые известны букетами ошибок. Если даже аргумент приходит в (const) char *, безопаснее сначала сделать из него std::string и после этого сравнивать с чем угодно без глупых подсчётов числа букв.

Лично у меня стоит автоформатирование при коммите, поэтому мне, если TODO был написал в одном коммите с самим кодом, автоформатирование не помогло бы.


Если даже аргумент приходит в (const) char *

Ждем-с string_view

В C++17 внесён, можно уже не ждать. Если категорически нужна совместимость со старым рантаймом, можно статически слинковаться с libstdc++. В любом случае, вряд ли копирование в std::string стало бы внезапно бутылочным горлом в этой функции, а профайлер прогонять всяко надо время от времени. Читабельность и надёжность кода же повысится в разы.

Про memcpy я немного погорячился, он попадается в методе обработки крэша, так что там может быть и оправдано. Всё-таки низкоуровневая логика сама по себе.
А эти результаты сообщены разработчикам inkscape?
Со своим уставом в чужой монастырь.
Про PVS-Studio vs Clang Static Analyzer читал уже неоднократно. Равно как и про то, как вы постоянно проверяете open source проекты. Какой смысл в этих проверках? В феврале вы проверяли FreeBSD, но что-то ваша работа незаметна на графике ошибок и их устранении.
PVS-Studio работает только под Windows и только с Visual Studio. Тогда чем вам не угодил open source? Да, open source с ошибками, а где их нет? На чужом несчастье счастья своего не построишь. Слышали такое?
After analyzing over 10 billion lines of code through Coverity Scan, the new 2014 Coverity Scan Open Source Report explains how:
Commercial code is more compliant to security standards than open source code
Defect density (defects per 1,000 lines of code) of open source code and commercial code has continued to improve since 2013
OpenSSL utilized Coverity Scan during their post-Heartbleed investigation
Early adoption of complimentary tools addressing legacy and newly written code is now truly a necessity
A responsible shift in best practices by open source leaders such as Linux, LibreOffice, NetBSD, and Apache Hadoop are helping to improve the general state of all open source software –highlighted by the improvements found in defect density from 2013 to 2014


Что касаемо inkscape, то его проверяют регулярно: https://scan.coverity.com/projects/inkscape

И заключительный вопрос: чем же ваша PVS-Studio интереснее Coverity?

Про PVS-Studio vs Clang Static Analyzer читал уже неоднократно.


Да, было такое. А скоро я и GCC «размажу по стенке» :). Статья уже есть. Но перед ней в очереди ещё несколько, так что придётся подождать.


Какой смысл в этих проверках?


Смысл проверок — реклама PVS-Studio. Благодаря её, у нас появляются новые клиенты, многие из которых используют PVS-Studio вот уже в течении нескольких лет.


В феврале вы проверяли FreeBSD, но что-то ваша работа незаметна на графике ошибок и их устранении.


И не должна. Мы всегда говорим, что разовые проверки не имеют смысла и годятся только как реклама. Смысл статического анализа в регулярном использовании. Вот если его ежедневного год использовать, тогда можно будет заметить вклад.


PVS-Studio работает только под Windows и только с Visual Studio.


Это скоро изменится.


Тогда чем вам не угодил open source? Да, open source с ошибками, а где их нет? На чужом несчастье счастья своего не построишь. Слышали такое?


Эээ..


Что касаемо inkscape, то его проверяют регулярно: https://scan.coverity.com/projects/inkscape


Отлично. Это значит, что мы легко находим ошибки уже после Coverity. Наш анализатор становится всё круче и круче.


И заключительный вопрос: чем же ваша PVS-Studio интереснее Coverity?


У PVS-Studio лучше соотношение эффективность/цена.

Кстати, о Coverty. А не думали так же проверять анализаторы? Вряд ли у них открыты исходники, но получилось бы крайне иронично.
А как проверка с помощью PVS-Studio должна была быть заметна на сайте Coverty?
UFO just landed and posted this here
В ожидании линукса — есть «свободная» реализация Bios/UEFI для 100+ материнских плат по имени CoreBoot. Проект периодически проверяется Coverity. Есть ли в планах проверка такой экзотики?
Это другое — http://coreboot.org, к проверенному там куском относится возможность собрать этот самый UEFI в качествe payload-а.
Sign up to leave a comment.