Программная ошибка

— Программная ошибка это ошибка в компьютерном программном обеспечении .

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

Последствия программной ошибки варьируются от незначительных (например, слово с ошибкой в ​​пользовательском интерфейсе ) до серьезных (например, частые сбои ).

Ошибки программного обеспечения были связаны с катастрофами. Программные ошибки в Therac-25 аппарате лучевой терапии были прямой причиной смертности пациентов в 1980-х годах. В 1996 году прототип ракеты Ariane 5 Европейского космического агентства стоимостью 1 миллиард долларов США был уничтожен менее чем через минуту после запуска из-за ошибки в бортовой компьютерной программе наведения. В 1994 году разбился вертолет Королевских ВВС «Чинук» , в результате чего погибло 29 человек; Первоначально в этом обвиняли ошибку пилота, но позже было решено, что это произошло из-за ошибки программного обеспечения в компьютере управления двигателем . начала XXI века Программное обеспечение с ошибками стало причиной скандала в Британском почтовом отделении .

В 2002 году исследование, проведенное по заказу торговли Министерства Национального института стандартов и технологий США , пришло к выводу, что «ошибки или ошибки в программном обеспечении настолько распространены и настолько вредны, что они обходятся экономике США примерно в 59 миллиардов долларов в год, или около 0,6 миллиарда долларов США». процентов валового внутреннего продукта».

С 1950-х годов некоторые компьютерные системы были разработаны для обнаружения или автоматического исправления различных ошибок программного обеспечения во время операций.

История

Дополнительная информация: Ошибка (инженерия) § История.

Терминология

Метаморфизм ошибки (от греческого Meta = «изменение», morph = «форма») относится к развитию дефекта на заключительном этапе развертывания программного обеспечения. Трансформация «ошибки», допущенной аналитиком на ранних этапах жизненного цикла разработки программного обеспечения, которая приводит к «дефекту» на заключительном этапе цикла, получила название «метаморфизм ошибки».

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

Споры

Иногда использование ошибки для описания поведения программного обеспечения является спорным из-за восприятия. Некоторые предлагают отказаться от этого термина; заменен с дефектом или ошибкой .

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

Некоторые утверждают, что ошибка может быть использована для сокрытия преднамеренного дизайнерского решения. В 2011 году, после проверки со стороны сенатора США Эла Франкена за запись и хранение местонахождения пользователей в незашифрованных файлах, Apple назвала такое поведение ошибкой. Однако Джастин Брукман из Центра демократии и технологий прямо оспорил это представление, заявив: «Я рад, что они исправляют то, что они называют ошибками, но я возражаю против их решительного отрицания того, что они отслеживают пользователей».

Профилактика

Ошибка, возникшая из-за ошибки программного обеспечения, отображается на двух экранах на станции Ла-Круа-де-Берни во Франции.

Предотвращение ошибок как можно раньше в процессе разработки программного обеспечения является целью инвестиций и инноваций.

Языковая поддержка

Новые языки программирования, как правило, разрабатываются так, чтобы предотвращать распространенные ошибки, возникающие из-за уязвимостей существующих языков. Уроки, извлеченные из старых языков, таких как BASIC и C, используются при разработке более поздних языков, таких как C# и Rust .

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

float num = "3";

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

Некоторые языки исключают функции, которые легко приводят к ошибкам, за счет снижения производительности — принцип заключается в том, что обычно лучше писать более простой, медленный и правильный код, чем сложный код с ошибками. Например, Java не поддерживает арифметику указателей , которая обычно выполняется быстро, но считается опасной; относительно легко вызвать серьезную ошибку.

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

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

Техники

Такие методы программирования, как стиль программирования и защитное программирование, предназначены для предотвращения опечаток.

Например, ошибка может быть вызвана относительно незначительной типографской ошибкой (опечаткой) в коде. Например, этот код выполняет функцию foo только если conditionэто правда.

if (condition) foo();

Но этот код всегда выполняется foo:

if (condition); foo();

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

if (condition) {
  foo();
}

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

Спецификация

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

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

Тестирование программного обеспечения

Одной из целей тестирования программного обеспечения является поиск ошибок.

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

Гибкие практики

Гибкая разработка программного обеспечения может включать частые выпуски программного обеспечения с относительно небольшими изменениями. Дефекты выявляются по отзывам пользователей.

При разработке через тестирование (TDD) модульные тесты пишутся во время написания производственного кода, и рабочий код не считается завершенным, пока все тесты не завершатся успешно.

Статический анализ

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

Инструментарий

Инструменты для мониторинга производительности программного обеспечения во время его работы, либо специально для обнаружения проблем, таких как узкие места , либо для обеспечения уверенности в правильной работе, могут быть встроены в код явно (возможно, так же просто, как утверждение, говорящее PRINT "I AM HERE") или предоставляются в качестве инструментов. Зачастую бывает неожиданно обнаружить, какой фрагмент кода занимает большую часть времени, и такое исключение предположений может привести к переписыванию кода.

Открытый исходный код

Разработка с открытым исходным кодом позволяет любому изучить исходный код. Школа мысли, популяризированная Эриком С. Рэймондом как закон Линуса, гласит, что популярное программное обеспечение с открытым исходным кодом имеет больше шансов иметь мало ошибок или вообще не содержать их, чем другое программное обеспечение, потому что «при достаточном количестве глаз все ошибки неглубоки». Однако это утверждение оспаривается: специалист по компьютерной безопасности Элиас Леви писал, что «легко скрыть уязвимости в сложном, малопонятном и недокументированном исходном коде», потому что «даже если люди просматривают код, это не значит, что они квалифицированы для этого». Примером ошибки программного обеспечения с открытым исходным кодом была уязвимость OpenSSL 2008 года в Debian .

Отладка

Основная статья: Отладка

Отладка может составлять значительную часть жизненного цикла разработки программного обеспечения . Морис Уилкс , пионер вычислительной техники, описал свое осознание в конце 1940-х годов, что «Большую часть оставшейся жизни мне предстояло потратить на поиск ошибок в моих собственных программах».

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

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

Некоторые утверждают, что обнаружение ошибки — это своего рода искусство.

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

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

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

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

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

Некоторые ошибки обнаруживаются при вводе данных, которые программисту может быть сложно воссоздать. Одной из причин гибели радиационной машины Therac-25 была ошибка (в частности, состояние гонки ), которая возникала только тогда, когда оператор машины очень быстро вводил план лечения; чтобы научиться это делать, потребовались несколько дней практики, поэтому ошибка не проявилась ни при тестировании, ни когда производитель пытался ее воспроизвести. Другие ошибки могут перестать возникать всякий раз, когда установка дополняется для поиска ошибки, например, при запуске программы с помощью отладчика; их называют ошибками Гейзенберга (в шутку названными в честь принципа неопределенности Гейзенберга ).

С 1990-х годов, особенно после катастрофы рейса 501 Ariane 5 , возрос интерес к автоматизированным средствам отладки, таким как статический анализ кода посредством абстрактной интерпретации .

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

Во встроенных системах программное обеспечение часто модифицируется для устранения аппаратной ошибки, поскольку это дешевле, чем модификация оборудования.

Управление

Пример истории ошибок ( GNU Classpath данные проекта ). Новая ошибка изначально не подтверждена. Как только воспроизводимость подтверждена, она меняется на подтвержденную . Как только проблема будет решена, она изменится на исправленную .

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

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

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

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

Серьезность

Серьезность — это мера воздействия ошибки. Это воздействие может выражаться в потере данных, финансовых потерях, потере репутации и напрасной трате усилий. Уровни серьезности не стандартизированы, но различаются в зависимости от контекста, например, от отрасли и инструмента отслеживания. Например, сбой в видеоигре имеет иные последствия, чем сбой на банковском сервере. Уровнями серьезности могут быть сбой или зависание , отсутствие обходного решения (пользователь не может выполнить задачу), наличие обходного решения (пользователь все еще может выполнить задачу), визуальный дефект (например, орфографическая ошибка) или ошибка документации . Другой пример набора степеней серьезности: критический , высокий , низкий , блокирующий , тривиальный . Серьезность ошибки может быть отдельной категорией по сравнению с приоритетом ее исправления, или же обе категории могут определяться количественно и управляться отдельно.

Ошибка, достаточно серьезная, чтобы задержать выпуск продукта, называется пробкой показа .

Приоритет

Приоритет описывает важность устранения ошибки по отношению к другим ошибкам. Приоритеты могут быть числовыми, например от 1 до 5, или именованными, например критический , высокий , низкий и отложенный . Значения могут быть аналогичны или идентичны рейтингам серьезности, хотя приоритет является другим аспектом.

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

Пластырь

Ошибки достаточно высокого приоритета могут потребовать специального выпуска, который иногда называют патчем .

Релиз обслуживания

Выпуск программного обеспечения, в котором особое внимание уделяется исправлению ошибок, можно назвать выпуском сопровождения , чтобы отличить его от выпуска, в котором особое внимание уделяется новым функциям или другим изменениям.

Известная проблема

Обычной практикой является выпуск программного обеспечения с известными ошибками низкого приоритета или другими проблемами. Возможные причины включают, помимо прочего:

• Срок должен быть соблюден, а ресурсов недостаточно, чтобы исправить все ошибки к сроку.

• Ошибка уже исправлена ​​в следующем выпуске и не имеет высокого приоритета.

• Изменения, необходимые для исправления ошибки, являются слишком дорогостоящими или затрагивают слишком много других компонентов, что требует серьезного тестирования.

• Можно подозревать или знать, что некоторые пользователи полагаются на существующее ошибочное поведение; предлагаемое исправление может привести к критическим изменениям

• Проблема заключается в области, которая устареет с предстоящим выпуском; исправлять это ненужно

• «Это не баг, это фича» Существует недопонимание между ожидаемым и фактическим поведением или недокументированной функцией.

Подразумеваемое

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

Помимо ущерба, причиненного ошибками, часть их стоимости связана с усилиями, затраченными на их исправление. В 1978 году Лиенц и др. показало, что в среднем 17 процентов усилий по разработке вкладывают в исправление ошибок. Исследование репозиториев GitHub в 2020 году показало, что медиана составляет 20%.

Расходы

НАСА В 1994 году Центру космических полетов имени Годдарда удалось снизить среднее количество ошибок с 4,5 на 1000 строк кода ( SLOC ) до 1 на 1000 SLOC.

Другое исследование, проведенное в 1990 году, показало, что исключительно хорошие процессы разработки программного обеспечения могут обеспечить уровень неудач при развертывании всего 0,1 на 1000 SLOC. Эта цифра повторяется в такой литературе, как «Code Complete » Стива МакКоннелла , и исследование НАСА по сложности программного обеспечения для полетов . Некоторые проекты даже достигли нулевых дефектов: прошивка пишущей машинки IBM Wheelwriter , состоящая из 63 000 SLOC, и программное обеспечение Space Shuttle с 500 000 SLOC.

Контрольный показатель

Чтобы облегчить воспроизводимые исследования по тестированию и отладке, исследователи используют тщательно подобранные тесты ошибок:

• эталон Сименс
• МногиеОшибки является эталоном 185 ошибок C в девяти программах с открытым исходным кодом.
• Дефекты4J представляет собой тест на 341 ошибку Java из 5 проектов с открытым исходным кодом. Он содержит соответствующие патчи, охватывающие различные типы патчей.

Типы

Некоторые известные типы ошибок:

Ошибка проектирования

Ошибка может быть вызвана недостаточным или неправильным проектированием согласно спецификации. Например, учитывая, что спецификация должна располагать список слов в алфавитном порядке, может возникнуть ошибка проектирования, если в проекте не учитываются символы; что приводит к неправильному алфавитному расположению слов с символами.

Арифметика

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

Поток управления

См. также: Логическая ошибка.

Ошибка потока управления , также известная как логическая ошибка, характеризуется кодом, который не завершается с ошибкой, но не имеет ожидаемого поведения, такого как бесконечный цикл , бесконечная рекурсия , неправильное сравнение в условном выражении , например использование неправильного оператора сравнения , и ошибка отклонения на единицу .

Интерфейс

• Неправильное использование API.
• Неправильная реализация протокола.
• Неправильное обращение с оборудованием.
• Неверные предположения о конкретной платформе.
• Несовместимые системы. Может показаться, что новый API или протокол связи работает, когда две системы используют разные версии, но могут возникнуть ошибки, когда функция или функция, реализованная в одной версии, изменяется или отсутствует в другой. В производственных системах, которые должны работать непрерывно, остановка всей системы для масштабного обновления может быть невозможна, например, в телекоммуникационной отрасли. или Интернет. В этом случае меньшие сегменты большой системы обновляются индивидуально, чтобы минимизировать сбои в работе большой сети. Однако некоторые разделы могут быть пропущены и не обновлены, что приведет к ошибкам совместимости, которые может быть сложно найти и исправить.
• Неправильные аннотации кода.

Параллелизм

• Тупик — задача не может продолжаться, пока не завершится вторая, но в то же время вторая не может продолжаться, пока не завершится первая.
• Состояние гонки — несколько одновременных задач конкурируют за ресурсы.
• Ошибки в критических секциях , взаимные исключения и другие особенности параллельной обработки . Время проверки до времени использования (TOCTOU) — это форма незащищенной критической секции.

Ресурсы

См. также: Ошибка выполнения.

• Разыменование нулевого указателя .
• Использование неинициализированной переменной .
• Использование в противном случае допустимой инструкции для неправильного типа данных (см. упакованное десятичное / двоично-десятичное число ).
• Нарушения доступа .
• Утечки ресурсов, когда конечный системный ресурс (например, память или дескрипторы файлов ) исчерпывается в результате повторного выделения без освобождения.
• Переполнение буфера , при котором программа пытается сохранить данные за пределами выделенного хранилища. Это может привести или не привести к нарушению доступа или нарушения хранения . Часто это ошибки безопасности .
• Чрезмерная рекурсия, которая, хотя и логически допустима, вызывает переполнение стека .
• Ошибка использования после освобождения, когда указатель используется после того, как система освободила память, на которую он ссылается.
• Двойная бесплатная ошибка.

Синтаксис

См. также: Синтаксическая ошибка.

• Использование неправильного токена , например, выполнение присваивания вместо проверки на равенство . Например, в некоторых языках x=5 устанавливает значение x равным 5, а x==5 проверяет, равно ли x в данный момент 5 или какому-то другому числу. Интерпретируемые языки допускают сбой такого кода. Скомпилированные языки могут обнаружить такие ошибки еще до начала тестирования.

Работа в команде

• Нераспространяемые обновления; например, программист меняет «myAdd», но забывает изменить «mySubtract», который использует тот же алгоритм. Эти ошибки смягчаются философией «Не повторяйся» .
• Комментарии устарели или неверны: многие программисты полагают, что комментарии точно описывают код.
• Различия между документацией и продуктом.

В политике

Отчет «Ошибки в системе»

Институт открытых технологий, которым управляет группа New America , в августе 2016 года опубликовала отчет «Ошибки в системе», в котором говорится, что политикам США следует провести реформы, чтобы помочь исследователям выявлять и устранять ошибки программного обеспечения. В отчете «подчеркивается необходимость реформы в области обнаружения и раскрытия уязвимостей программного обеспечения». Один из авторов отчета заявил, что Конгресс недостаточно сделал для решения проблемы уязвимости киберпрограммного обеспечения, хотя Конгресс принял ряд законопроектов по борьбе с более широкой проблемой кибербезопасности.

Правительственные исследователи, компании и эксперты по кибербезопасности — это люди, которые обычно обнаруживают недостатки программного обеспечения. В докладе содержится призыв к реформированию законов о компьютерной преступности и авторском праве.

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

В популярной культуре

• В видеоиграх термин « сбой » иногда используется для обозначения ошибки в программном обеспечении. Примером может служить глюк и неофициальный вид покемонов MissingNo.
• И в романе 1968 года « 2001: Космическая одиссея» , и в соответствующем фильме 1968 года « 2001: Космическая одиссея» бортовой компьютер космического корабля HAL 9000 пытается убить всех членов его экипажа. В последующем романе 1982 года « 2010: Одиссея 2» и сопровождающем его фильме 1984 года «2010» раскрывается, что это действие было вызвано тем, что компьютер был запрограммирован на две противоречивые цели: полностью раскрыть всю свою информацию и сохранить истинная цель полета скрыта от экипажа; этот конфликт привел к тому, что HAL стал параноиком и в конечном итоге стал склонен к убийству.
• В английской версии песни Nena 1983 года 99 Luftballons (99 красных воздушных шаров) в результате «ошибок в программном обеспечении» выпуск группы из 99 красных воздушных шаров ошибочно принимается за запуск вражеской ядерной ракеты, что требует эквивалентной реакции на пуск. , что привело к катастрофе.
• В американской комедии 1999 года « Офисное пространство » трое сотрудников пытаются (безуспешно) воспользоваться озабоченностью своей компании компьютерной ошибкой 2000 года, используя компьютерный вирус, который отправляет на их банковский счет округленные доли копейки — давно известный метод, называемый салями . нарезка .
• Роман «Ошибка » Эллен Уллман 2004 года повествует о попытке программиста найти неуловимую ошибку в приложении базы данных.
• Канадский фильм 2008 года «Контроль, альтернатива, удаление» рассказывает о программисте, который в конце 1999 года пытается исправить ошибки в своей компании, связанные с проблемой 2000 года.

См. также

• Антипаттерн
• Программа вознаграждения за ошибки
• Удаление глюков
• Аппаратная ошибка
• ISO/IEC 9126 , который классифицирует ошибку как дефект или несоответствие .
• Список ошибок программного обеспечения
• Классификация ортогональных дефектов
• Проблема с гоночной трассой
• Дайджест РИСКИ
• Индикатор дефекта программного обеспечения
• Программная регрессия
• Программное гниение
• Автоматическое исправление ошибок

Внешние ссылки

• « Перечисление общих слабостей » - веб-страница экспертов, посвященная ошибкам, на NIST.gov.
• ОШИБКА типа Джима Грея – еще один тип ошибки.
• Изображение «первой компьютерной ошибки» в Wayback Machine (архивировано 12 января 2015 г.)
• « Первая компьютерная ошибка! » - электронное письмо от 1981 года об ошибке адмирала Хоппера.
• « К пониманию ошибок компилятора в GCC и LLVM ». Исследование ошибок в компиляторах 2016 года.