Комментарии 20
Вы офигенны =)
Мощно! Ошибки уже исправлены? Или у каждого читающего есть шанс оставить свою частичку в коде CoreCLR?
Пока не исправлены. Но не думаю, что стоит пытаться сделать правки. Мы уведомим разработчиков. Пусть они проанализируют статью и поправят то, что является ошибкой. Заодно, возможно посмотрят и другие предупреждения анализатора.
Иначе, начнётся давка. Уже было. Доходит до смешного. Например, надо поменять местами первый и второй аргумент функции. Один ошибку исправляет, а другой возвращает на место, вновь (по невнимательности) обменяв аргументы местами.
Иначе, начнётся давка. Уже было. Доходит до смешного. Например, надо поменять местами первый и второй аргумент функции. Один ошибку исправляет, а другой возвращает на место, вновь (по невнимательности) обменяв аргументы местами.
Очень много ошибок действительно таковыми являются, и по сути только те, что связаны с условиями, находятся в разряде предположений. А от memcpy объектов вообще как-то даже неуютно. Помнится у меня был коллега-джуниор, который после «new» в C++ вызывал «memset» с фразой «Любая память после выделения должна быть обнулена». Наподобие подход и здесь, думаем о памяти, а не объектах.
Насчет давки согласен, вспоминаю обзор исходников Qt'a — там тоже было полно доступных исправлений.
P.S. Кстати, пока писал историю про memset вспомнил другое — в одном проекте я видел кастомные операторы «new», которые не bad_alloc выкидывали, а NULL возвращали. Ваш анализатор умеет понимать, какой «new» используется?
Насчет давки согласен, вспоминаю обзор исходников Qt'a — там тоже было полно доступных исправлений.
P.S. Кстати, пока писал историю про memset вспомнил другое — в одном проекте я видел кастомные операторы «new», которые не bad_alloc выкидывали, а NULL возвращали. Ваш анализатор умеет понимать, какой «new» используется?
В одном проекте я видел кастомные операторы «new», которые не bad_alloc выкидывали, а NULL возвращали. Ваш анализатор умеет понимать, какой «new» используется?
Мы знаем, что такие new бывают. Можно подключить специальные либы, где 'new' будет возвращать 0. Но как получить такую информацию для анализатора не понятно. Поэтому, на эту тему ничего специального не сделано. Если используется new, возвращающий 0, то можно просто отключить эту диагностику в настройках анализатора.
А как оператор new ведет себя с включенной опцией /EHa в Visual C++? Случаем не 0 возвращает?
Помоему /EH* опции влияют всего-лишь на их методы вылавливания. А вот чтобы стандартный оператор *new* не кидал исключение надо ему указать «std::nothrow»:
char * c = new (std::nothrow) char[x];
if (c == nullptr) {
…
}
тогда такая проверка нужна.
char * c = new (std::nothrow) char[x];
if (c == nullptr) {
…
}
тогда такая проверка нужна.
С *new* тоже не все так просто как раньше мне казалось, кроме двух версий его вызовов(простой и с этим «nothrow») я недавно узнал что есть еще один когда *new* не выделяет новую память, а размещает объект по заданному адресу, вызывая конструктор:
void * somePtr = getPtr();
new (somePtr) T;
Но в данном случае не будет вызван деструктор после уничтожении того участка памяти где находился наш объект, что логично. Потому в таких случаях надо вручную вызывать деструктор, если в нем есть какая-то логико, конечно.
void * somePtr = getPtr();
new (somePtr) T;
Но в данном случае не будет вызван деструктор после уничтожении того участка памяти где находился наш объект, что логично. Потому в таких случаях надо вручную вызывать деструктор, если в нем есть какая-то логико, конечно.
Это называется Placement new. И про это анализатор тоже, конечно, знает.
Про (std::nothrow) анализатор знает и промолчит.
Пока некто KOLANICH github.com/dotnet/coreclr/issues/474 оставил репорт.
В принципе если создадите пул-реквест и там сошлетесь на эту ошибку — то ссылка на пул-реквест появится в ней.
В принципе если создадите пул-реквест и там сошлетесь на эту ошибку — то ссылка на пул-реквест появится в ней.
Начали править: github.com/dotnet/coreclr/pull/476/files
А у вас есть аналогичная проверка исходного кода OpenJDK? Было бы интересно глянуть.
OpenJDK не проверяли.
P.S. Обновляемый список open-source проектов, которые мы проверили с помощью PVS-Studio.
P.S. Обновляемый список open-source проектов, которые мы проверили с помощью PVS-Studio.
И оно же работает! Может не трогать? (как в том анекдоте)
Вот вы спалите хату Микрософту и они вас скупят на корню! :)
Добрались и до CoreFX: Новогодняя проверка .NET Core Libraries (CoreFX)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PVS-Studio: 25 подозрительных фрагментов кода из CoreCLR