Pull to refresh

Comments 14

Хотелось бы задать вопрос, а ответили ли Вам как-нибудь разработчики в связи с этой статьей? Или это конфеденциальная информация? Можете сказать, купили ли какие-либо компании ваш анализатор после того, как был проанализирован код их приложений?
Ответили ли Вам как-нибудь разработчики в связи с этой статьей? Или это конфеденциальная информация?

Не отвечали. Вообще, отвечают где-то только в 60% случаев. И в основном это «спасибо, поправим». Остальные тихо поправляют ошибки и всё.

Можете сказать, купили ли какие-либо компании ваш анализатор после того, как был проанализирован код их приложений?

Да, было. Но это скорее исключение из правила. Разработчики open-source хотят инструменты бесплатно. И иногда мы предоставляем им бесплатные лицензии. Не всем. Open-source — он разный бывает. В любом случае, мы и не стремимся им продать. Эти статьи повод другим людям узнать о нас, попробовать и купить, если продукт понравится.
Пролистал обе статьи, не нашёл указания версии проверяемого VitrualBox. Какую версию проверяли?
Не до конца читали.
Часто к нашим статьям задают одни и те же вопросы. Ответы на них мы собрали здесь: Ответы на вопросы читателей статей про PVS-Studio и CppCat, версия 2014. Пожалуйста, ознакомьтесь со списком.

Там написано, что для проверки сливается trunk. Плюс некоторое время уходит на сборку/анализ проекта, анализ результатов и написание статьи.
trunk это не версия, если что. Сегодня он ссылается на один коммит, а завтра на другой. Например, было бы интересно посмотреть историю с той версии, которая проверялась анализатором, и trunk (допустим на момент прочтения статьи).
С транком всё понятно, просто читателей в основном интересует «свежак» это или «не свежак». Я только записываю номер ревизии, чтобы ответить на вопросы разработчиков, если они связываются после прочтения статьи. Версию проекта только иногда смотрю, потому что в разных проектах информацию о версии хранят по-разному, и я ищу её только если есть острая необходимость.
а почему бы не сказать в статье что за ревизию проверили?
sizeof(sizeof(...)) и проверка на NULL глобального массива доставили!
К сожалению, для многих: «Это не те дроны, которых вы ищете». Не знаю правда, как это не ошибки, если вот они. Пример дискуссии на эту тему.
....
A>Это такой троллинг. Дело в том, что масса программистов читая наши статьи с презрительным «фи» говорит, что такие ошибки они не допускают,

Не допускают.

A>а если и допускают, то находят их за 10 секунд. Вот мы и сделали ограничение в минуту. И выясняется, что очень даже их сразу и не заметишь.

Не допускают. Искать нечего.



Гм. А что тогда делают ошибки в коде, который мы видим в тестах? Или вот это что такое?

И не надо про студентов. Это Clang, Qt, Chromium, Boost и так далее.



Логично было бы спросить у авторов соответствующих продуктов.

У нас же, как и у большинства отметившихся в теме, приняты coding conventions, которые уменьшают саму вероятность забытых скобок, используются code review, в принципе не пропускающие говнокод, и код покрывается юнит-тестами, которые банально покрывают не только приведенные Вами в пример ошибки, но еще и огромный класс других потенциальных ошибок (логических, например), перед которыми Ваш продукт все равно бессилен.

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


Кстати, как-то пропустил вашу эту буктопуху.
Что скажу — она ругается «неправильно», когда я ткнул в правильную ошибку. Во второе её место.
Например, i.piccy.info/i9/ff38ce4b0c72f50ab2a8c97abe99c6d2/1416068504/144321/301300/33.png
Я нажал на "==" в строчке с memcmp, показывая что это == стоит не там. Не засчитало, имхо, не заслуженно :)
В итоге в конце «правильно» засчитало 10 из 15, когда реально я ошибся (точнее, не увидел ошибки) только один раз.
Бебебе :P
Почитал комменты на рсдн… да…
p.s.: редкий вопрос потребовал более 15 секунд на поиск ошибки.
Для работы с строками типа wchar_t* следует использовать спецификатор %S, а не %s.
Если бы был sprintf_s, то это было бы верно. А swprintf_s меняет %S и %s на противоположные.

msdn.microsoft.com/en-us/library/hf4y5e3w.aspx
s
When used with printf functions, specifies a single-byte or multi-byte character string; when used with wprintf functions, specifies a wide-character string.

S
When used with printf functions, specifies a wide-character string; when used with wprintf functions, specifies a single-byte or multi-byte character string.

То есть %s — это «нативный» тип строки, а %S — отличающийся, требующий преобразования.
Да, в статье ошибка. Надо поправить статью.
Анализатор говорит про пятый, а не четвёртый аргумент. Ошибка с печатью символа, а не строки.
Написано:
swprintf_s(wszDest, RT_ELEMENTS(wszDest), L"%s%c", pwszDestDir, '\0');

А надо:
swprintf_s(wszDest, RT_ELEMENTS(wszDest), L"%s%c", pwszDestDir, L'\0');

Несущественная ошибка. На практике ничего плохого не будет.
Sign up to leave a comment.