Ответ 1

C определяют UsB, UB и IDB таким образом, который можно суммировать следующим образом:

Неопределенное поведение (UsB)

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

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

Подводя итог: стандарт дает некоторые возможности выбора, реализация выбирает, когда и как выбирается и применяется конкретная альтернатива.

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

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

Undefined Поведение (UB)

Как указано в названии, это ситуация, когда стандарт C не налагает или не гарантирует, что программа должна или должна делать. Все ставки сделаны. Такая ситуация:

• делает программу ошибочной или непереносимой

• не требует абсолютно ничего из реализации

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

Другими словами, наличие причины UB позволяет реализации полностью игнорировать стандарт, если речь идет о запуске программы UB.

Обратите внимание, что фактическое поведение в этом случае может охватывать неограниченный диапазон возможностей, это далеко не полный список:

• Может быть выпущена ошибка времени компиляции.
• Может быть выпущена ошибка времени выполнения.
• Проблема полностью игнорируется (и это может привести к ошибкам программы).
• Компилятор молча удаляет UB-код в качестве оптимизации.
• Ваш жесткий диск может быть отформатирован.
• Ваш компьютер может стереть ваш банковский счет и спросить у вашей подруги дату.

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

Примечание по терминологии:. Иногда люди утверждают, что часть кода, которую стандарт считает источником UB в своей реализации/системе/среде, документирована, поэтому это не может быть действительно UB. Это рассуждение неверно, но это общее (и несколько понятное) недоразумение: когда термин UB (а также UsB и IDB) используется в контексте C, это означает технический термин, чей < сильное > точное значение определяется стандартом (стандартами). В частности, слово "undefined" теряет свой повседневный смысл. Поэтому нет смысла показывать примеры, когда ошибочные или непереносимые программы производят "четко определенное" поведение в качестве контрпримеров. Если вы попробуете, вы действительно упустите момент. UB означает, что вы теряете все гарантии стандарта. Если ваша реализация предусматривает расширение, ваши гарантии будут только теми, которые вы выполняете. Если вы используете это расширение, ваша программа больше не является совместимой программой C (в некотором смысле, это не более программа на C, поскольку она больше не соответствует стандарту!).

Полезность поведения undefined

Общий вопрос об UB - это что-то в этих строках: "Если UB настолько противный, почему не стандартный мандат на реализацию ошибки при столкновении с UB?"

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

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

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

Выполняемое при реализации поведение (IDB)

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

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

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

Примеры неуказанного поведения

Порядок оценки

Аргументы функции

Порядок оценки аргументов функции не указан EXP30-C.

Например, в c(a(), b()); не указано, вызывается ли функция a до или после b. Единственная гарантия заключается в том, что оба вызываются до функции c.

Примеры поведения undefined

Указатели

Выделение нулевого указателя

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

Технически это поведение undefined. Однако, поскольку это очень распространенный источник ошибок, большинство C-сред гарантируют, что большинство попыток разыменования нулевого указателя немедленно сбой программы (обычно убивая его с ошибкой сегментации). Эта защита не идеальна из-за арифметики указателя, связанной с ссылками на массивы и/или структуры, поэтому даже с помощью современных инструментов разыменование нулевого указателя может форматировать ваш жесткий диск.

Выделение неинициализированного указателя

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

Выделение недействительных указателей

Недопустимый указатель - это указатель, который содержит адрес, который не находится в пределах выделенной области памяти. Обычными способами создания недействительных указателей является вызов free() (после вызова указатель будет недействительным, что в значительной степени является точкой вызова free()), или для использования арифметики указателя для получения адреса, который выходит за пределы выделенного блока памяти.

Это самый злой вариант разыменования указателей UB: нет защитной сетки, предупреждения о компиляторе нет, есть только тот факт, что код может что-то сделать. И обычно это происходит: Большинство вредоносных атак используют этот вид поведения UB в программах, чтобы заставить программы вести себя так, как они хотят, чтобы они вели себя (например, установка трояна, кейлоггера, шифрование вашего жесткого диска и т.д.). Возможность форматированного жесткого диска становится очень реальной с таким типом UB!

Устранение констелляции

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

int const a = 42;
...
int* ap0 = &a;      //< error, compiler will tell us
int* ap1 = (int*)a; //< silences the compiler
...
*ap1 = 43;          //< UB ==> program crash?

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

категория 2

введите здесь название!

разместите свое объяснение здесь!

Примеры поведения, определяемого реализацией

категория 1

введите здесь название!

разместите свое объяснение здесь!

Ответ 2

N1570 - это проект стандарта ISO C, очень близкий к официальному документу ISO.

N1256 - это более ранний черновик, включающий стандарт C99 плюс изменения из трех технических исправлений.

Приложение J имеет 5 разделов, каждый из которых собирает информацию, которая разбросана по остальной части стандарта:

• J.1 Неопределенное поведение
• J.2 Undefined поведение
• J.3 Поведение, определяемое реализацией
• J.4 Локальное поведение
• J.5 Общие расширения