Comments 24
А у вас не было желания проверить AOSP?
0
Во-первых, это неполноценный анализ. Какие-то ошибки ускользнут от анализатора. Возможно, появится некоторое количество ложных срабатываний. Во-вторых, в таком случае нет смысла приводить статистику ложных/позитивных срабатываний, так как на собранном проекте она может измениться любым образом.
Разработчики отметили, что найденные анализатором фрагменты кода действительно являются ошибками, поблагодарили, и сообщили, что со временем ошибки будут исправлены.
Может статистику по ошибкам всё же выложите?
+1
Статистику предупреждений анализатора по уровням?
Я могу поискать лог, но я не высчитывал процент FA, и, повторюсь (впрочем, вы это самы процитировали), что на собранном проекте кол-во предупреждений может быть несколько больше или меньше.
Я могу поискать лог, но я не высчитывал процент FA, и, повторюсь (впрочем, вы это самы процитировали), что на собранном проекте кол-во предупреждений может быть несколько больше или меньше.
0
Но раз уж сами разработчики подтвердили, что найденные ошибки — это ошибки, то было бы любопытно узнать, сколько их нашёл анализатор и сколько из них разработчиками отклонено как «ложные», если такое было.
0
Поймите, что мы проверяем множество проектов, а не сидим над одним в течении месяца. То о чём здесь говорится большая, кропотливая задача. И самое главное, результаты недостоверны и непонятно, что с ними делать. Допустим окажется, что что-то из описанного в статье ошибкой не является. И что? Здесь скорее виноваты мы, так как не разбираемся в проекте. И наоборот, анализатор мог предупреждать о серьезном баге, а мы прошли мимо, опять-таки не зная проект. Подобную статистику ещё могут попробовать собрать разработчики проекта. Но они тоже этим заниматься не станут.
0
Вам надо добавить в анализатор фичу по автоматической генерации статей на хабр: проверил проект — опубликовалась рекламная статья. Их количество в единицу времени тогда возрастет. Или оно уже так?
-5
В WiKi их ещё 6 лет назад забанили за спам.
https://en.wikipedia.org/wiki/MediaWiki_talk:Spam-whitelist/Archives/2009/04#Viva64.com
https://en.wikipedia.org/wiki/MediaWiki_talk:Spam-whitelist/Archives/2009/04#Viva64.com
+1
Ну прям спам… Человек (которого уже давно как с нами нет) разместил неудачно несколько ссылок. Кстати, вполне по теме. Но уже тогда нашелся один из наших «почитателей», который приложил усилия и добился бана. Глупая история и нет смысла злорадствовать. Я думаю википедия только потеряла от того, что нельзя давать ссылки на некоторые наши образовательные материалы.
0
UFO just landed and posted this here
Помучившись со сборкой, я все же решил проверить проект 'как есть'.
Удивляет подход разработчиков, разобраться не разобрались, но статью держите!
-3
Не разобрались?
Я пробовал собрать как решение 'из коробки' с разными конфигурациями, так и собирал проект через скрипт. Несмотря на то, что на GitHub на странице проекта не рекомендуют для сборки Visual Studio, написал разработчикам, чтобы удостовериться, что .sln необходим только для удобства работы, но не для сборки. Убедился, что всё нормально собирается через скрипт (с использование .Net Core). И описал эти ситуации, а также плюсы и минусы проверки собранного и несобранного проекта.
Я бы не назвал это 'не разобрались'.
Я пробовал собрать как решение 'из коробки' с разными конфигурациями, так и собирал проект через скрипт. Несмотря на то, что на GitHub на странице проекта не рекомендуют для сборки Visual Studio, написал разработчикам, чтобы удостовериться, что .sln необходим только для удобства работы, но не для сборки. Убедился, что всё нормально собирается через скрипт (с использование .Net Core). И описал эти ситуации, а также плюсы и минусы проверки собранного и несобранного проекта.
Я бы не назвал это 'не разобрались'.
+1
Это как-то меняет ценность найденных ошибок?
+2
Это допустимо для меня (как рядового пользователя), не разобраться и «хоть как-то» проверить свой проект.
Но Вы, если уж беретесь за такое дело, такого не должны допускать. А то выходит очередная гордая статья с заголовком — «МЫ ПРОВЕРИЛИ проект N», а потом начинается — «тут не разобрались», «анализатор что-то указал, но мы не знаем реальная это ошибка или нет», «вникать в проект нет сил» и т.д.
Но Вы, если уж беретесь за такое дело, такого не должны допускать. А то выходит очередная гордая статья с заголовком — «МЫ ПРОВЕРИЛИ проект N», а потом начинается — «тут не разобрались», «анализатор что-то указал, но мы не знаем реальная это ошибка или нет», «вникать в проект нет сил» и т.д.
-3
А Вам не стыдно обвинять, не имея на это основания? Ещё не известно, кто у кого и что заимствует. Не буду показывать пальцем.
Впрочем, я не вижу на самом деле у кого-то специального умысла в пересечениях. Многие вещи просто лежат на поверхности.
И если Вы про V3095, то брали мы её из PVS-Studio C++ V595 (диагностика существует с 2012 года).
Впрочем, я не вижу на самом деле у кого-то специального умысла в пересечениях. Многие вещи просто лежат на поверхности.
И если Вы про V3095, то брали мы её из PVS-Studio C++ V595 (диагностика существует с 2012 года).
0
Справедливости ради, в Klocwork эта диагностика с версии 9.2 — то есть она там была уже как минимум с конца 2011 года (согласно википедии, версия 9.5 вышла в январе 2012, других дат я не нашел).
Но лично я не вижу ничего плохого в копировании полезной диагностики — если никто не будет копировать чужие диагностики, то в итоге надо будет каждому покупать 10-20 анализаторов. Кроме того, я не вижу причин, по которым одна и та же идея не может придти в голову разным людям независимо.
+1
Уточнил. Диагностика появилась в версии 4.39 (November 25, 2011). А запланирована она была скорее всего ещё за полгода-год до того.
0
Очень интересно наблюдать, как сотрудники PVS-Studio всем своим штатом начинают ставить минуса за неугодные их публикациям комментарии.
-1
Sign up to leave a comment.
Продолжаем проверять проекты Microsoft: анализ PowerShell