Andrey2008 31 авг 2016 в 16:47

Находим ошибки в коде компилятора GCC с помощью анализатора PVS-Studio

14 мин

24K

Блог компании PVS-StudioC*C++*Информационная безопасность*Разработка под Linux*

+72

Комментарии 48

perfect_genius 31 авг 2016 в 19:00

Не боитесь, что проверяемый «проглотит» свои же эти ошибки и далее не даст их совершать?

Т.е. разработчики учтут и внесут дополнительные проверки.

TheKnight 31 авг 2016 в 19:24

А чего им боятся то? ~~Всех не перевешают!~~ Проверку всех ошибок, находимые PVS-Studio в ближайшее время вряд ли кто то сможет перенести что в Clang что в GCC. Так что им хватит еще на хлеб с маслом.

Andrey2008 31 авг 2016 в 19:27

Даже если так, это не страшно. Мы ведь тоже не стоим на месте. Собственно, наша задача всегда бежать впереди компиляторов.

НЛО прилетело и опубликовало эту надпись здесь

miraage 31 авг 2016 в 19:46

А GCC разве не люди писали? Каждый из нас может допустить подобного рода ошибку.

EvgeniyRyzhkov 31 авг 2016 в 20:35

Ах эта вера в то, что есть по-настоящему крутые программисты, которые не допускают ошибок…

Jef239 1 сен 2016 в 03:44

И чем ближе человек к чайнику — тем больше в это верит. :-) Иллюзии уходят с написанием первого компилятора. :-)

theg4sh 31 авг 2016 в 19:24

Частенько читаю ваши статьи на хабре и порой выношу для себя полезные вещи (спасибо!), но не могу припомнить ответа на вопрос: «Сообщаете ли Вы мэнтейнерам продуктов о найденных ошибках?»

Andrey2008 31 авг 2016 в 19:25

Толсто. Но на всякий случай, если не троллинг: да (см. ответы на часто задаваемые вопросы, ссылка в конце статьи).

Newbilius 1 сен 2016 в 08:33

Мне кажется, что стоит упоминать об этом не в FAQ на стороннем сайте, а прямо в статье. Статья ведь должна в идеале быть самодостаточной, а одна строчка «мы сообщаем о багах авторам софта» сильно её не увеличит. Это для вас ваши статьи относятся к некой серии, а читатель может начать с любой из них.

Так что думаю нет, это не троллинг комментатора, а (мелкая?) недоработка автора статьи. Данный комментатор мог часто читать ваши статьи, но не ходить в FAQ — и это, имхо, нормально.

EvgeniyRyzhkov 1 сен 2016 в 08:48

Если в каждую статью вставлять про «отписали разработчикам», про «версию для линукс», про «проверяете ли PVS-Studio», то статьи будут похожи на юридический текст. Что главное нисколько не помешает первым вопросом написать: «А вы проверяете PVS-Studio своим анализатором?».

Shultc 1 сен 2016 в 11:50

Вы не правы: всё писать не нужно. Проверка PVS-Studio самой собой не относится к теме стати, и версия для линукса тоже слабо… А вот то, что об этих конкретных ошибках, о которых написано в статье было сообщено разработчиком — является неотъемлемой частью повествования.

Это как снимать фильм про какого-нибудь супер-героя, но концовку не делать, потому что ведь и без того понятно, что герой всегда побеждает.

LoadRunner 1 сен 2016 в 12:46

В конкретно данном случае сложность с этим:

К сожалению, я не могу выдать разработчикам компилятора полный отчёт.

А вообще, уже традицией стало задавать вопрос про то, сообщили ли разработчикам. Эпиком стал этот комментарий.
Но в последнее время этот вопрос перестали задавать, народ расслабился и уже в комментариях к этой статье вылезло сразу несколько F.A.Q.-овых вопросов.

EvgeniyRyzhkov 1 сен 2016 в 12:56

является неотъемлемой частью повествования

Для Вас — это. Для других — другое является такой же частью.

theg4sh 1 сен 2016 в 17:37

Именно этот текст вставлять не обязательно.
Все же было бы приятно видедь ссылку в конце поста на соответствующий репорт (хотя бы по тому, что уже нашлось среди «мусора»), согласитесь? По крайней мере для меня, статья выглядела бы полностью законченной в плане текущей истории.

theg4sh 1 сен 2016 в 17:19

Не могу понять, в чем увидели троллинг с моей стороны, когда действительно было интересно это узнать.

P.S. Да, виноват, под кат не заглянул.

maksqwe 31 авг 2016 в 19:57

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421

theg4sh 1 сен 2016 в 17:19

Благодарю.

SkidanovAlex 31 авг 2016 в 21:37

Интересно, может ли вот этот код привести к проблемам:

strncmp (xloc.file, "\1", 2)

Из-за того, что строка, с которой сравнивают, имеет длину 1, а длина указана как 2.

splav_asv 31 авг 2016 в 22:07

Таки длина 2. К строкам, полученным из литералов автоматически добавляется нулевой байт.

SkidanovAlex 31 авг 2016 в 23:11

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

Andrey2008 31 авг 2016 в 22:13

Функция strncmp() сравнивает в лексикографическом порядке не более count символов из двух строк, заканчивающихся символом конца строки, и возвращает целое значение, зависящее от результата сравнения следующим образом. Если в какой-нибудь из заданных строк меньше count символов, сравнение заканчивается при обнаружении первого нулевого символа.

ZyXI 1 сен 2016 в 00:59

Я не вижу в стандарте ничего про «лексикографический порядок». Даже, наоборот:

The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp is determined by the sign of the difference between the values of the first pair of characters (both interpreted as unsigned char) that differ in the objects being compared.

(C99, 7.21.4) — просто сравниваются байты. Для «лексикографического порядка» есть strcoll, правда, не знаю, насколько хорошо оно работает (в первую очередь, насколько хорошо оно работает с UTF-8, с однобайтовыми локалями всё обычно в порядке).

Andrey2008 1 сен 2016 в 09:07

Ну подумаешь, скопировал неудачное описание с просторов интернета. :) Суть не меняется.

unabl4 31 авг 2016 в 22:48

А если PVS Studio проверит PVS Studio, что будет? ))

Andrey2008 31 авг 2016 в 22:50

Проверяем исходный код плагина PVS-Studio с помощью PVS-Studio

TheLonerD 1 сен 2016 в 00:21

Будет заминусованный коммент, так-то.

unabl4 1 сен 2016 в 11:27

Не понятно только за что, ну да ладно.

EvgeniyRyzhkov 1 сен 2016 в 11:45

За оригинальность.

justhabrauser 31 авг 2016 в 22:48

Когда уже будет «Находим ошибки в коде анализаторе PVS-Studio с помощью анализатора PVS-Studio»?

Andrey2008 31 авг 2016 в 22:50

См. выше.

justhabrauser 1 сен 2016 в 18:06

Это последствия премодерации комментариев от «самых маленьких». Пока мой комментарий был на модерации — произошла накладка.

IGR2014 1 сен 2016 в 09:07

Я ждал этого момента!
Спасибо за интересную статью. Теперь знаю чего ждать от любимого компилятора.

Superl3n1n 1 сен 2016 в 09:07

А каким компилятором скомпилирован PVS-Studio for linux?

Andrey2008 1 сен 2016 в 09:08

GCC

LoadRunner 1 сен 2016 в 09:13

Тогда статью можно было назвать так: Проверяем GCC, скомпилированный GCC, анализатором PVC-Studio, скомпилированным GCC.

Muxto 1 сен 2016 в 11:45

Рекурсивненько

EvgeniyRyzhkov 1 сен 2016 в 12:57

И пишем в Ворде, собираемом Microsoft.

LoadRunner 1 сен 2016 в 13:38

В этом?

alan008 1 сен 2016 в 13:50

Ошибки PVS-Studio, вызванные ошибками GCC, выявленными PVS-Studio, скомпилированной с помощью GCC, могут являться на самом деле не ошибками PVS-Studio, а ошибками GCC :))

1KoT1 1 сен 2016 в 10:00

Мне кажется, или в вашем примере кода лишняя скобка перед '?'?

Приоритет тернарного оператора ?: ниже, чем у оператора сравнения <=. Это значит, что мы имеем дело с условием вида:
(die_offset > 0 &&
  (die_offset <= (loc->dw_loc_opc == DW_OP_call2)) ?
    0xffff : 0xffffffff);

Andrey2008 1 сен 2016 в 10:02

Поправлю. Прошу писать про замеченные недостатки в личку.

veydlin 1 сен 2016 в 10:32

Было бы очень интересно узнавать, по мимо ошибок, как вызвать эти ошибки в самой программе
Например, что можно написать в программе и скомпилировать её GCC, чтобы была магия?