Вызывает ли макрос offsetof из ‹stddef.h› неопределенное поведение?

Там, где стандарт языка говорит о «неопределенном поведении», любой данный компилятор может определить поведение. Код реализации в стандартной библиотеке обычно зависит от этого. Итак, есть два вопроса:

(1) Соответствует ли код UB стандарту C++?

Это действительно сложный вопрос, потому что общеизвестным практически дефектом является то, что стандарт C++98/03 никогда прямо не говорит в нормативном тексте, что в общем случае разыменование нулевого указателя является UB. Это подразумевается из-за исключения для typeid, где это не UB.

Что вы можете сказать решительно, так это то, что использовать offsetof с типом, отличным от POD, — это UB.

(2) Является ли код UB по отношению к компилятору, для которого он написан?

Нет, конечно нет.

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

Ура и чт.,

Понятие «неопределенное поведение» неприменимо к реализации стандартной библиотеки, независимо от того, макрос это, функция или что-то еще.

В общем случае стандартную библиотеку не следует рассматривать как реализованную на языке C++ (или C). Это относится и к стандартным файлам заголовков. Стандартная библиотека должна соответствовать своей внешней спецификации, но все остальное — это детали реализации, освобожденные от всех и любых других требований языка. Стандартную библиотеку всегда следует рассматривать как реализованную на каком-то «внутреннем» языке, который может быть очень похож на C++ или C, но все же не является C++ или C.

Другими словами, макрос, который вы цитируете, не приводит к неопределенному поведению, если это конкретно макрос offsetof, определенный в стандартной библиотеке. Но если вы сделаете точно то же самое в своем коде (например, точно так же определите свой собственный макрос), это действительно приведет к неопределенному поведению. «Quod licet Jovi, non licet bovi».

Когда стандарт C указывает, что определенные действия вызывают неопределенное поведение, это обычно не означает, что такие действия были запрещены, а скорее то, что реализации могут свободно указывать последующее поведение или нет по своему усмотрению. Следовательно, реализации могут свободно выполнять такие действия в тех случаях, когда Стандарт требует определенного поведения, если и только если реализации могут гарантировать, что поведение для этих действий будет соответствовать тому, что требует Стандарт. Рассмотрим, например, следующую реализацию strcpy:

char *strcpy(char *dest, char const *src)
{
  ptrdiff_t diff = dest-src-1;
  int ch;
  while((ch = *src++) != 0)
    src[diff] = ch;
  return dest;
}

Если src и dest являются несвязанными указателями, вычисление dest-src приведет к неопределенному поведению. Однако на некоторых платформах соотношение между char* и ptrdiff_t таково, что при любом char* p1, p2 вычисление p1 + (p2-p1); всегда будет равно p2. На платформах, которые дают такую ​​гарантию, приведенная выше реализация strcpy будет законной (и на некоторых таких платформах может быть быстрее, чем любая правдоподобная альтернатива). Однако на некоторых других платформах такая функция всегда может завершаться ошибкой, за исключением случаев, когда обе строки являются частью одного и того же выделенного объекта.

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

Это в основном эквивалентно вопросу, является ли это UB:

s* p = 0;
volatile auto& r = p->m;

Ясно, что доступ к памяти для цели r не генерируется, потому что это volatile, а компилятору запрещено генерировать ложные обращения к volatile переменным. Но *s не является изменчивым, поэтому компилятор может сгенерировать доступ к нему. Ни оператор адреса, ни приведение к ссылочному типу не создают неоцененный контекст в соответствии со стандартом.

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

Наконец, примечание в разделе [dcl.ref] говорит

в частности, нулевая ссылка не может существовать в четко определенной программе, потому что единственный способ создать такую ​​ссылку — это привязать ее к «объекту», полученному путем разыменования нулевого указателя, что приводит к неопределенному поведению.

Это НЕ неопределенное поведение в C++, если m находится по смещению 0 в структуре s, а также в некоторых других случаях. Согласно проблеме 232 (выделено мной) :

Унарный оператор * выполняет косвенность: выражение, к которому он применяется, должно быть указателем на тип объекта или указателем на тип функции, а результатом является значение lvalue, относящееся к объекту или функции, на которую указывает выражение, если таковые имеются. . Если указатель является нулевым значением указателя (7.11 [conv.ptr]) или указывает на единицу после последнего элемента массива объекта (8.7 [expr.add]), результатом является пустое lvalue, не относящееся ни к какому объекту или функции. Пустое значение lvalue нельзя изменить.

Следовательно, &((s *)0)->m является неопределенным поведением, только если m не находится ни по смещению 0, ни по смещению, соответствующему адресу, который находится на единицу позже последнего элемента объекта массива. Обратите внимание, что добавление смещения 0 к null разрешено в C++, но не в C.

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

Нет, это НЕ неопределенное поведение. Выражение разрешается во время выполнения.

Обратите внимание, что он берет адрес члена m из нулевого указателя. Это НЕ разыменование нулевого указателя.