PVS-Studio corporate blog
Open source
.NET
Mono & Moonlight
C#
Comments 32
0
Я не специалист по шарпу, но что не так с SetErrorInfo? Нормальный out-параметр, нет? Ну, если бы это были плюсы, там бы стояла ссылка &
+2

Out параметры в C# помечаются словом… out ;-).
PS: ох сколько потенциальных багов может быть...

+2
А сам рантайм не проверяли? Он на C, порядка 300к строк, тот еще кошмар :)
+4
Я точно не добрался, коллеги вроде тоже не проверяли.
Если бы там что-то нашлось, в рамки этой статьи вместить уже точно не удалось бы (тогда бы её точно не стал никто читать из-за размера) :)
UFO landed and left these words here
UFO landed and left these words here
+5
Позволю себе предположить и разъяснить вам то, почему, по моему мнению «минусуют» — Ваш коментарий не несет никакой смысловой нагрузки, как по отношению к статье, так и к другим коментариям, более того, сам по себе коментарий не несет в себе никакой полезной информации, которая так или иначе, могла бы быть полезна/интересна читателю.
+1
Однако оператор явного приведения, в случае, если аргумент имеет значение null [...], не возвращает null [...],, а генерирует исключение типа InvalidCastException.

Это ошибочное утверждение. Null можно кастить к любому ссылочному типу, и результатом будет также null.

var x = (int?)null;
var y = (string)null;
var z = (System.Windows.Control)null;
+1
А вашему C# анализатору можно скормить Unity3D проект? Формально он собирается той же студией или Mono.
0

А вы их честно проверяете — или просто выдергиваете элементы Compile?

0
Что вы понимаете под 'честной проверкой'?
Проектные файлы используются в том числе и для получения компиляции, из которой извлекается семантическая информация, необходимая для глубокого анализа.
Я об этом писал в этой статье.
0

"Честная проверка" означает, что на вход анализатора попадают все участвующие в компиляции файлы, независимо от того, были ли они статически указаны в файле проекта.


Visual Studio, когда подсвечивает код, собирает файлы честно. По крайней мере, 2012я версия — точно. А вот разработчики R#, к примеру, схалтурили...

0
У меня в некоторых статических классах есть метод Dispose, назван так по аналогии с методом Dispose интерфейса IDisposable, т.к. тоже выполняет очистку ресурсов. PVS студия рекомендует наследоваться от него (V3074), но статические классы нельзя наследовать от интерфейсов. Можно обучить анализатор не выдавать такой совет для статических классов.
0
И еще такой момент, есть код:

 if (periods == null || periods.Count() == 0) { /*...*/  }


Выдает на него следующее:
V3063. A part of conditional expression is always true/false if it is evaluated


Но ведь здесь все логично, проверка или идет до первого срабатывания слева направо, если коллекция не null, хочу проверить наличие элементов в ней. Если бы здесь стояло логическое И, то ошибка была бы понятна, т.к. были бы взаимоисключающие части условия.
0
Да, понял почему выдается предупреждение, periods при расчете не может быть инициализирован null значением, но с другой стороны результат вычисляется на две функции вглубь в другом месте, так что проверку все таки оставить стоит, подстраховаться на случай смены реализации расчета, и возможности возврата null.
В общем, все правильно он показал.
0
А его не нужно оборачивать в using, это часть инфраструктурного функционала, который должен работать в течение всего жизненного цикла приложения. Например, в моем случае, это: логирование, планировщик задач по умолчанию, и реализация сигналов. Конечно каждый из вариантов можно сделать не статическим, но в этом случае снизится удобство использования (субъективно).
Например, идея которую предлагает log4net или NLog, где в каждом классе нужно получать логгер, плюс писать что то вроде logger.Log.Info кажется избыточным, а вот идея писать в любом месте Log.Info() минималистичнее и удобнее.
+1
Статический метод с сайд-эффектом — зло в квадрате. Рано или поздно появится необходимость переписать. Уж лучше статическое поле, вроде Log.Current.Info() и Log.Current.Dispose() соответственно.
-1
Вопрос в подходе, с теми же логами мне удобно чтобы логи не летели куда-то в централизованное хранилище логов. А лежали непосредственно в файловой системе рядом с приложением. Т.е. в 100% случаев все приложения пишут лог рядом с собой в ФС. Соответственно нужна только одна реализация, переписывать которую не приходилось и вряд ли придется.
-1

Игра всё таки была не очень сложная, т.к. определить тип ошибки по виду кода было не очень сложно — первым вариантом было последовательное присвоение, вторым — именно одинаковое условие в двух частях тернарного оператора. Беглым просмотром находится идентичные части.


Найди в реальном коде? Сначала подумалось что гораздо сложнее. Потом вдумался. Если я правильно понимаю что делает код, то он выставляет цвет нажатой кнопки. Заметив "баг" будет довольно очевидно, где его искать. Так что, ИМХО, пример для "найди ошибку сам" можно было сделать и посложнее.

0
А вы сообщали разработчиках о найденых ошибках? Есть позитивный опыт общения с ними?
Мой случай закончился никак: я обнаружил причину, почему циклы с Thread.Sleep(1) на Mac OS/iOS жрут 100% CPU, но мейнтейнер репорт не понял, а в итоге перестал рассматривать.
0

Все мы люди, Alexis действительно просто не понял вас :-). Попробую сейчас пингануть кого-нибудь.

0
Круто, спасибо!
Еще бы чуть больше информации как именно пофиксили — нашли свое решение, или через usleep? Да и закрытый тикет не помешал бы :)
0

Я в подробности не вникал, но проблема не воспроизводится в мастере, но воспроизводится в текущем 4.6. Т.е. фикс из мастера забэкпортят в 4.6 позже. Удалось убедить Мигеля в наличии проблемы скриншотами :-). Тикет должны будут закрыть.

Only those users with full accounts are able to leave comments. , please.