Что такое ошибка при компиляции
Ошибки компиляции
ПРИМЕЧАНИЕ: Эти ошибки обычно не выводят окно и просто показывают » Build Failed » в выводе компилятора. Если появляется окно, то это обычно ошибка Runner Error, которая объясняется здесь.
Все сообщения об ошибках компилятора будут иметь одинаковый формат:
Если ошибка найдена в сценарии, то это будет просто:
Затем вы можете дважды щелкнуть на любой из записей об ошибке компилятора, чтобы открыть данный актив в позиции, отмеченной как дающая ошибку, и затем вы можете использовать информацию, содержащуюся в сообщении. можно использовать информацию, содержащуюся в сообщении, чтобы точно определить, где именно в объекте или сценарии произошла ошибка. Однако иногда эти ошибки могут показаться немного загадочными, поэтому ниже вы найдете полный список всех ошибок и краткое объяснение того, что они означают:
Разное
Струны
Скрипты, Функции и аргументы
Ожидаемые символы/значения
Ошибки и предупреждения компилятора и средств сборки C/C++
В статьях, приведенных в этом разделе документации, объясняются сообщения об ошибках и предупреждения диагностики, созданные компилятором Microsoft C/C++ и средствами сборки.
компиляторы Visual Studio и средства сборки могут сообщать о различных типах ошибок и предупреждений. После обнаружения ошибки или предупреждения средства сборки могут сделать предположения о намерениях кода и попытаться продолжить, чтобы в одно и то же время можно было сообщить больше проблем. Если средства делают неверное предположение, последующие ошибки или предупреждения не могут применяться к проекту. При устранении проблем в проекте всегда начинайте с первой зарегистрированной ошибки (или предупреждения) и выполняйте повторную сборку как можно чаще. Одно из исправлений может привести к удалению нескольких последующих ошибок.
Ссылки на дополнительные ресурсы справки и сообщества см. в разделе Visual C++ справки и Community.
В этом разделе
Ошибки и предупреждения BSCMAKE (BKxxxx)
Ошибки и предупреждения, создаваемые служебной программой «Просмотр информации» (BSCMAKE.EXE).
Ошибки и предупреждения командной строки
Ошибки и предупреждения, создаваемые средствами сборки для параметров командной строки.
Предупреждения компилятора с C4000 по C5999
Предупреждения для проблем, обнаруженных компилятором C++ (CL.EXE).
Предупреждения компилятора по версиям компилятора
Список предупреждений, появившихся каждой версией компилятора.
Ошибки среды выполнения C (Rxxxx)
Ошибки, формируемые во время выполнения библиотекой времени выполнения C (CRT).
Ошибки и предупреждения CVTRES (CVTxxxx)
Ошибки и предупреждения, созданные с помощью файла ресурсов Майкрософт в программе преобразования объектов COFF (CVTRES.EXE).
Ошибки вычислителя выражений (CXXxxxx)
Ошибки, создаваемые отладчиком и средствами диагностики.
Ошибки и предупреждения средств компоновщика (LNKxxxx)
Ошибки и предупреждения, созданные компоновщиком и связанными инструментами (LINK.EXE, LIB.EXE, DUMPBIN.EXE, EDITBIN.EXE).
Математические ошибки (Mxxxx)
Ошибки, создаваемые математической библиотекой среды выполнения с плавающей запятой.
Ошибки и предупреждения NMAKE (Uxxxx)
Ошибки и предупреждения, создаваемые инструментом Microsoft Makefile (NMAKE.EXE).
Ошибки и предупреждения профильной оптимизации (Пгкскскскс)
Ошибки и предупреждения, созданные средствами оптимизации Profile-Guided (PGO).
Ошибки и предупреждения режима сборки проекта (PRJxxxx)
ошибки и предупреждения, созданные в машинном коде C++ Project системы сборки в Visual Studio.
Сообщения векторизатора и параллелизатора
Диагностические сообщения, создаваемые параметрами компилятора векторизатора и параллелизатора Optimization.
Находим ошибки в коде компилятора GCC с помощью анализатора PVS-Studio
GNU Compiler Collection (обычно используется сокращение GCC) — набор компиляторов для различных языков программирования, разработанный в рамках проекта GNU. GCC является свободным программным обеспечением, распространяется фондом свободного программного обеспечения на условиях GNU GPL и GNU LGPL и является ключевым компонентом GNU toolchain. Проект написан на языке C и C++.
Компилятор GCC имеет хорошие встроенные диагностики, помогающие выявлять многие ошибки на этапе компиляции. Естественно, GCC собирается с помощью GCC и, соответственно, может выявлять ошибки в собственном коде. Дополнительно исходный код GCC проверяется с помощью анализатора Coverity. Да и вообще, думаю GCC проверялся энтузиастами с помощью многих анализаторов и других инструментов. Это делает поиск ошибок в GCC большим испытанием для анализатора кода PVS-Studio.
Для анализа была взята trunk версия из git-репозитория: (git) commit 00a7fcca6a4657b6cf203824beda1e89f751354b svn+ssh://gcc.gnu.org/svn/gcc/trunk@238976
Примечание. Статья задержалась с выходом, и возможно какие-то ошибки уже исправлены. Но это не имеет значения: постоянно появляются новые ошибки, старые исчезают. Главное — статья показывает, что статический анализ может помогать программистам выявлять ошибки после их появления.
Предвидя дискуссию
Как я сказал во введении, я считаю GCC проектом с высоким качеством кода. Уверен, многие захотят поспорить. В качестве примера приведу цитату из Wikipedia на русском языке:
Некоторые разработчики OpenBSD, например Тео де Раадт и Отто Мурбек (Otto Moerbeek), критикуют GCC, называя его «громоздким, глючным, медленным и генерирующим плохой код».
Я считаю такие заявления необоснованными. Да, возможно, код GCC содержит много макросов, которые затрудняют его чтение. Но я никак не могу согласиться с заявлением о его глючности. Если бы GCC глючил, вообще бы нигде ничего не работало. Вы только вспомните, как много программ им компилируется и успешно работает. Создатели GCC делают огромную, сложную работу с большим профессионализмом. Спасибо им. Я рад, что могу протестировать работу PVS-Studio на таком высококачественном проекте.
Для тех, кто скажет, что код компилятора Clang всё равно круче, напомню: в нём PVS-Studio также находил ошибки: 1, 2.
PVS-Studio
Я проверил код GCC с помощью Alpha-версии анализатора PVS-Studio for Linux. Мы планируем начать выдавать заинтересовавшимся программистам Beta-версию анализатора в середине сентября 2016 года. Инструкцию о том, как стать одним из первых, кто сможет попробовать Beta-версию PVS-Studio for Linux на своём проекте, вы найдете в статье «PVS-Studio признаётся в любви к Linux».
Если вы читаете эту статью гораздо позже, чем сентябрь 2016, и хотите попробовать PVS-Studio for Linux, то приглашаю вас на страницу продукта: http://www.viva64.com/ru/pvs-studio/
Результаты проверки
Мы добрались до самого интересного раздела, который, я думаю, с нетерпением ждут наши постоянные читатели. Рассмотрим участки кода, где анализатор нашел ошибки или крайне подозрительные моменты.
К сожалению, я не могу выдать разработчикам компилятора полный отчёт. В нем пока слишком много мусора (ложных срабатываний), связанных с тем, что анализатор не полностью готов к встрече с миром Linux. Нужно проделать работу по уменьшению количества ложных предупреждений на типовые используемые конструкции. Попробую пояснить на одном простом примере. Многие диагностики не должны ругаться на выражения, относящиеся к макросам assert. Эти макросы бывают устроены весьма творчески и надо научить анализатор не обращать на них внимание. Но дело в том, что определяется макрос assert очень по-разному, и надо обучить анализатор всем типовым вариантам.
Поэтому разработчиков GCC прошу подождать выхода по крайней мере Beta-версии анализатора. Я не хочу испортить впечатление отчетом, сгенерированным недоделанной версией.
Классика (Copy-Paste)
Начнем мы с самой классической и распространённой ошибки, которая выявляется с помощью диагностики V501. Как правило, такие ошибки появляются из-за невнимательности при Copy-Paste или просто являются опечатками, допускаемыми при наборе нового кода.
Предупреждение анализатора PVS-Studio: V501 There are identical sub-expressions ‘!strcmp(a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1)’ to the left and to the right of the ‘&&’ operator. dwarf2out.c 1428
Быстро увидеть ошибки проблематично и следует внимательно присмотреться. Именно поэтому ошибка и не была выявлена при обзорах кода и рефакторинге.
Функция strcmp дважды сравнивает одни и те же строки. Мне кажется, второй раз следовало сравнивать не члены класса lbl1, а lbl2. Тогда корректный код должен выглядеть так:
Хочу отметить, что код, приведённый в статье, немного отформатирован, чтобы он занимал мало места по оси X. На самом деле, код выглядит так:
Ошибки, возможно, удалось бы избежать, если использовать «табличное» выравнивание кода. Например, ошибку было бы легче заметить, если отформатировать код так:
Подробнее я рассматривал такой подход в электронной книге «Главный вопрос программирования, рефакторинга и всего такого» (см. главу N13: Выравнивайте однотипный код «таблицей»). Рекомендую всем, кто заботится о качестве своего кода, познакомиться с приведённой здесь ссылкой.
Давайте рассмотрим ещё одну ошибку, которая, я уверен, появилась из-за Copy-Paste:
Предупреждение анализатора PVS-Studio: V519 The ‘has_avx512vl’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 500, 501. driver-i386.c 501
В переменную has_avx512vl дважды подряд записываются различные значения. Это не имеет смысла. Я изучил код и обнаружил переменную has_avx512ifma. Скорее всего, именно она и должна инициализироваться выражением ebx & bit_AVX512IFMA. Тогда корректный код должен быть таким:
Опечатка
Продолжу испытание вашей внимательности. Посмотрите на код и, не подсматривая ниже, попробуйте найти ошибку.
Предупреждение анализатора PVS-Studio: V528 It is odd that pointer to ‘char’ type is compared with the ‘\0’ value. Probably meant: *xloc.file == ‘\0’. ubsan.c 1472
Здесь программист случайно забыл разыменовать указатель в выражении xloc.file == ‘\0’. В результате указатель просто сравнивается с 0, т.е. с NULL. Никакого эффекта это не имеет, так как ранее такая проверка уже выполнялась: xloc.file == NULL.
Хорошо, что терминальный ноль программист записал как ‘\0’. Это помогает быстрее понять, что код ошибочен и как его надо исправить. Про это я также писал в книге (см. главу N9: Используйте для обозначения терминального нуля литерал ‘\0’).
Правильный вариант кода:
Хотя, давайте ещё немного улучшим код. Я рекомендую отформатировать выражение так:
Обратите внимание: теперь, если допустить ту же ошибку, шанс её заметить будет чуть-чуть выше:
Потенциальное разыменование нулевого указателя
Ещё этот раздел можно было бы назвать «стотысячный пример, почему макросы — это плохо». Я очень не люблю макросы и всегда призываю поменьше их использовать. Макросы затрудняют чтение кода, провоцируют появление ошибок, усложняют работу статическим анализаторам. Как мне показалось из недолгого общения с кодом GCC, его авторы очень любят макросы. Я замучался изучать, во что раскрывается тот или иной макрос и возможно поэтому пропустил немало интересных ошибок. Признаюсь, я иногда бываю ленив. Но пару ошибок, связанных с макросами, я всё-таки продемонстрирую.
Предупреждение анализатора PVS-Studio: V595 The ‘odr_types_ptr’ pointer was utilized before it was verified against nullptr. Check lines: 2135, 2139. ipa-devirt.c 2135
Видите здесь ошибку? Думаю, нет, и сообщение анализатора ясности не вносит. Всё дело в том, что odr_types — это не имя переменной, а макрос, объявленным следующим образом:
Если раскрыть макрос и убрать всё не относящееся к делу, мы получим следующий код:
В начале указатель разыменовывается, а потом проверяется. Приведёт это к беде на практике или нет, сказать сложно. Все зависит от того, может ли возникнуть ситуация, когда указатель действительно будет равен nullptr. Если такая ситуация невозможна, то следует удалить лишнюю проверку, которая будет вводить в заблуждение людей, поддерживающих код и анализатор кода. Если указатель может быть нулевым, то это серьёзная ошибка, которая требует ещё большего внимания и исправления.
Рассмотрим ещё один аналогичный случай:
Предупреждение анализатора PVS-Studio: V595 The ‘list’ pointer was utilized before it was verified against nullptr. Check lines: 1627, 1629. sched-int.h 1627
Чтобы увидеть ошибку, нам опять потребуется показать устройство макроса:
Раскрываем макрос и получаем:
И сейчас многие воскликнут: «Стоп, стоп! Здесь нет ошибки. Мы ведь просто получаем указатель на член класса. Никакого разыменования нулевого указателя здесь нет. Да, возможно код не аккуратен, но ошибки здесь нет!».
Всё не так просто. Здесь возникает неопределённое поведение. И то, что такой код может работать на практике, это просто везение. На самом деле, так писать нельзя. Например, оптимизирующий компилятор, увидев list->first, может удалить проверку if (list). Раз мы выполняли оператор ->, значит предполагается, что указатель не равен nullptr. Если это так, то проверять указатель не нужно.
Я написал целую статью на эту тему: «Разыменовывание нулевого указателя приводит к неопределённому поведению». Там как раз рассматривается аналогичный случай. Прежде чем спорить, прошу внимательно познакомиться с этой статьёй.
Впрочем, рассмотренная ситуация действительно сложна и неочевидна. Я допускаю, что могу быть всё-таки неправ и ошибки здесь нет. Однако, до сих пор мне никто не смог это доказать. Будет интересно услышать комментарии разработчиков GCC, если они обратят внимание на эту статью. Уж они-то точно должны знать, как работает компилятор и следует ли интерпретировать такой код как ошибочный, или нет.
Использование разрушенного массива
Предупреждение анализатора PVS-Studio: V507 Pointer to local array ‘buf’ is stored outside the scope of this array. Such a pointer will become invalid. hsa-dump.c 704
Строка формируется во временном буфере buf. Адрес этого временного буфера сохраняется в переменной name и используется далее в теле функции. Ошибка в том, что после записи буфера в переменную name, сам этот буфер будет уничтожен.
Использовать указатель на разрушенный буфер нельзя. Формально мы имеем дело с неопределённым поведением. На практике этот код может вполне успешно работать. Корректная работа программы — это один из вариантов проявления неопределенного поведения.
В любом случае, этот код содержит ошибку и её необходимо исправить. Работать код может по той причине, что компилятор может посчитать ненужным использование временного буфера для последующего хранения других переменных или массивов. И тогда, хотя массив, созданный на стеке, считается разрушенным, на самом деле его может никто не трогать, и функция правильно выполнит свою работу. Вот только такое везение в любой момент может кончиться и код, который работал 10 лет, вдруг, при переходе на новую версию компилятора, начинает вести себя удивительнейшим образом.
Чтобы исправить ошибку, достаточно объявить массив buf в той же области видимости, что и указатель name:
Выполнение одинаковых действий, независимо от условия
Анализатор выявил участок кода, который однозначно я не могу идентифицировать как ошибочный. Однако, крайне подозрительно выполнить проверку, а потом, независимо от её результата, выполнять одни и те же действия. Конечно, возможно, это задел на будущее и пока всё корректно, но проверить этот участок кода явно стоит.
Предупреждение анализатора PVS-Studio: V523 The ‘then’ statement is equivalent to the ‘else’ statement. tree-ssa-threadupdate.c 2596
Если этот код ошибочный, я, к сожалению, не догадываюсь как его следует исправить. Это тот случай, когда надо быть знакомым с проектом, чтобы внести правку.
Предупреждение анализатора PVS-Studio: V590 Consider inspecting this expression. The expression is excessive or contains a misprint. gensupport.c 1640
Нас интересует условие: (alt mode == mode’ to the left and to the right of the ‘&&’ operator. expmed.c 2573
Два раза подряд проверяется mode, но зато нет проверки cost. Возможно, одно из сравнений нужно просто удалить, а возможно, нужно сравнивать cost. Мне сложно судить, но код явно стоит поправить.
Дубликаты присваиваний
Следующие участки кода, на мой взгляд, не представляют опасности и, кажется, дублирующееся присваивание можно просто удалить.
Предупреждение анализатора PVS-Studio: V519 The ‘structures’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 842, 845. gengtype.c 845
Предупреждение анализатора PVS-Studio: V519 The ‘nargs’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 39951, 39952. i386.c 39952
Последний случай более странный, чем остальные. Возможно, тут есть какая-то ошибка. Переменной steptype значение присваивается 2 или 3 раза. Это подозрительно.
Предупреждение анализатора PVS-Studio: V519 The ‘steptype’ variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 5173, 5174. tree-ssa-loop-ivopts.c 5174
Заключение
Я рад, что написал эту статью. Теперь мне есть что отвечать на комментарии вида «PVS-Studio не нужен, так как все те же предупреждения выдаёт и GCC». Как видите, PVS-Studio очень мощный инструмент и превосходит по диагностическим возможностям GCC. Я не отрицаю, что в GCC реализованы отличные диагностики. Этот компилятор, при должной настройке, действительно выявляет много проблем в коде. Но PVS-Studio — это специализированный и быстро развивающийся инструмент, а это значит, он всегда будет лучше выявлять ошибки в коде, чем это делают компиляторы.
Приглашаю познакомиться с проверками других известных открытых проектов, посетив этот раздел нашего сайта. А также, тем, кто использует Twitter, последовать за мной @Code_Analysis. Я регулярно публикую ссылки на интересные статьи по программированию на языке C и C++, а также рассказываю о новых достижениях нашего анализатора.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey karpov. Bugs found in GCC with the help of PVS-Studio.
Предупреждения компилятора в С++: принять нельзя отказать
Зашел у нас в Cloud4Y разговор о программировании в облаке и о том, какой язык программирования можно по праву считать самым «облачным». Долго ли котротко ли, дошли до обсуждения ошибок копмиляторов — о их двоякой натуре: и проигнорировать все нельзя, и обращать внимание на каждый — умом тронуться недолго. Сегодня мы представим вам небольшой сценарий обращения с предупреждениями компилятора, который позволит не пропустить грубую ошибку и сохранит нервную систему в порядке.
Мы часто видим предупреждения компилятора об участках кода, которые имеют потенциальные проблемы или плохой стиль. Иногда они указывают на код, который действительно не работает, поэтому не игнорируйте их.
Не игнорируйте предупреждения компилятора
Конечно, эти предупреждения не могут не раздражать; к тому же, чаще всего они возникают для идеально работающего кода, который точно не содержит багов.
Но будьте уверены, что одно из нескольких тысяч предупреждений компилятора действительно имеет смысл. Иногда мы пишем код, который компилируется, но работает не так, как мы предполагали. Так как же, во имя Хабра, определить, какое именно предупреждение указывает на реальную ошибку? Как отличить его от сотен других, при которых код действителен? Неужели нужно тратить столько времени на то, чтобы прочитать их все? Это практически невозможно.
Примите политику «без предупреждений»
Если уж совсем честно, то есть только две вещи, которые можно сделать с предупреждениями компилятора — игнорировать их или избавиться от них. Игнорировать их — значит выбросить в мусорное ведро инструмент, который поможет предотвратить баги. Согласитесь ли вы смотреть сквозь пальцы на наличие серьезных ошибок? Наверное, нет.
Измените свой код, чтобы избавиться от предупреждений
Хотя иногда нам и хочется, чтобы компилятор просто промолчал о конкретном предупреждении, лучше просто изменить код. Если код не понятен компилятору, то есть все шансы, что он не будет понятен и человеку тоже.
Прояснить свои намерения в коде часто достаточно, чтобы заставить замолчать компилятор. Некоторые компиляторы могут дать подсказку, как решить определенные предупреждения. Давайте посмотрим на часто появляющиеся предупреждения о присваивании в условном контексте:
Для Clang это выглядит так:
Второй случай, который лежит в основе этого предупреждения: иногда мы пишем a = b, когда мы имели в виду a == b.
В то время как другие компиляторы просто предупреждают, что написанное нами задание выглядит достаточно странно в этом участке кода, CLANG услужливо пытается угадать, что же мы могли иметь в виду.
Первый указатель просто говорит нам, как исправить предупреждение, если задание на самом деле так и было задумано. У GCC есть такое же предупреждение и предложение исправить, но без предоставления альтернативы:
Многие отдают предпочтение CLANG, так как он позволяет нам предположить, каково правильное решение. Это гораздо лучше, поскольку дает возможность найти в коде баг, чего не случилось бы, прими мы автоматически все, что предлагает компилятор.
Даже если присваивание действительно было запланировано, принятие предложения компилятора и добавление пары скобок могут быть неправильным решением.
С точки зрения чистого кода, мы должны разделить присваивание и условие. Гораздо удобнее иметь по одной строке для каждой задачи, то есть, по сути, применять Принцип Единой Ответственности на построчном базисе:
Не исправляйте предупреждений компилятора автоматически, вносите исправления только обдуманно.
Скажите компилятору, предупреждения какого типа важны для вас
Существует несколько способов, как работать с компилятором и не получать предупреждений. Естественно, написание кода, который понятен даже бедняге компилятору — лучшее решение. Однако есть также возможность сказать компилятору, какие предупреждения вас интересуют, а какие — нет.
Флаги компилятора
Каждый известный нам компилятор обеспечивает возможность выбора предупреждений, которые вы хотите видеть. Можно отключить различные группы предупреждений, а иногда можно переназначить отдельные предупреждения на другой уровень предупреждений. Обычно эти возможности предоставляются как параметры командной строки в настройках IDE. Это значит, что у вас может быть единственное место — предпочтительно ваш билд скрипт — где вы можете эти настройки применить.
Какие флаги предупреждений использовать? Это зависит частично от компилятора, поскольку разные компиляторы эмитируют разные предупреждения, и некоторые из них могут быть не просто ошибочными, а бредовыми.
Некоторые предупреждения могут быть слишком педантичными на ваш вкус или для вашего стиля написания кода, хотя нам до сих пор не встречались предупреждения, не имеющие под собой никаких оснований. (На наш взгляд вообще лучше просматривать все предупреждения, чтобы не пропустить важное).
Стандартные флаги для большинства предупреждений — это Wall, Wpedantic, Wextra (многие флаги компилятора, касающиеся предупреждений, начинаются с W).
Если вы только начинаете применять политику «без предупреждений» для своего проекта, вы, скорее всего, получаете сотни или даже тысячи предупреждений, если они все включены. Начните с более низкого уровня предупреждений. Зафиксируйте наиболее жесткие предупреждения и постепенно наберите свой уровень предупреждений.
Если вы подвержены моментам лени, или у вас есть коллеги, выступающие против политики «без предупреждений», то отключить их совсем будет не так то просто. У может возникнуть желание проверить код, содержащий соответствующее предупреждение. В конце концов, окажется, что это не ошибка, код компилируется и, вероятно, будет работать, как предполагалось. Таким образом куча предупреждений рассосется, одно за другим.
Директивы Pragma
Бывают случаи, когда вам не подходит использование #pragma.
Компилятор услужливо предлагал добавить дополнительные скобки. Это могло бы быть верным решением, будь операторы применяемы к числовым значениям. Чтобы код DSL читался, в таком случае требуется заглушить предупреждение, не трогая код, здесь поможет отключение предупреждения с помощью #pragma в комплексе с поясняющим комментарием.
Вместо заключения
Вы можете настроить компилятор, сообщив ему, какие предупреждения вам интересны, а какие — нет; используйте для этого аргументы командной строки или, если потребуется, директивы #pragmas. Старайтесь быть максимально строгими, не добавляйте слишком много исключений. Это означает осторожное использование #pragmas и отклонений от ваших стандартных аргументов командной строки.
Иногда ни один из перечисленных способов не является реалистичным решением. Тогда просто используйте для компилятора команду shut up.