Что, кажется, удалось выяснить к настоящему моменту:
Пример 1
Согласно
expr.unary.op.1, разыменование возвращает an lvalue referring to the object or function to which the expression points. Есть трактовка, что раз объекта нет, то UB, но, например, dangling ссылки сами по себе не UB несмотря на то, что исходного объекта нет. Еще есть довольно старая
CWG issue 232, где CWG пришла к неформальному консенсусу, что
p = 0; *p; is not inherently an error. Полагаю, что в этом примере UB нет.
Пример 2
Видно две потенциальные возможности UB. Разыменование освещено в предыдущем примере, поэтому здесь сфокусируюсь на операторе запятая. Согласно
expr.comma.1, операнды вычисляются слева направо, и то, что вернуло разыменование, становится discarded-value выражением. Неформальный консенсус в
CWG issue 232 также в том, что an lvalue-to-rvalue conversion would give it undefined behavior, но и его не происходит, потому что о
volatile речь у нас нигде не идет (
expr.context-2), не говоря о том, что в текущем тексте стандарта этот консенсус, кажется, тоже не отражен: в
conv.lval из релевантного только the value contained in the referenced object is not accessed, что наоборот предупреждает возможность UB (
basic.lval.11). Полагаю, что UB нет и здесь.
Пример 3
Полагаю, здесь UB начнется самое позднее на попытке доступа к несуществующему объекту под
p внутри конструктора копирования согласно
basic.lval.11.
Пример 4
Полагаю, здесь UB начнется в момент вызова функции-члена у несуществующего объекта согласно
class.mfct.non-static.1.
Пример 5
Если предположить, что разыменование, которое происходит согласно
59 сноске, само по себе допустимо, то далее я не нахожу требований, чтобы сам объект существовал, и, соответственно, причин для UB.
