const_cast и UB

а) Во-первых, использование слова «может». Почему это «может»? Другие места в Стандарте очень точно определяют поведение undefined.

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

Стандарт C ++ часто использует слова «может» или «мог бы», например:

1.3.12: Неопределенное поведение может также ожидаться, если в этом международном стандарте отсутствует описание какого-либо явного определения поведения.

Акцент мой. По сути, в стандарте используется слово «может», например, «разрешено» .

б) Почему отказ от константности изначально константного объекта не сразу приводит к «неопределенному поведению». Почему для запуска UB требуется запись?

Запись запускает UB, потому что на определенных платформах объекты const могут храниться в постоянной памяти.

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

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

Ex:

const int  x = 4;
const int *y = x;

*const_cast<int*>(x) = 3; // UB - the pointed-to object may 
                          // be in read-only memory or whatever.

int        a = 7;
const int *b = a;

*const_cast<int*>(b) = 6; // Not UB - the pointed-to object is 
                          // fundamentally mutable.

Комментарий ниже, потому что код в комментариях выглядит ужасно:

В §7.1. 5.1 / 4 стандарта приведен следующий пример:

int i = 2;
const int * cip; // pointer to const int
cip = &i;        // OK: cv-qualified access path to unqualified
...
int* ip;
ip = const_cast <int *>( cip ); // cast needed to convert const int* to int*
*ip = 4;                        // defined: *ip points to i, a non-const object

Так что это специально разрешено.

Что касается вашего первого вопроса, если что-то может вызывать неопределенное поведение, это не делает его менее неопределенным.

Что касается второй части, я полагаю, это из соображений совместимости. Например, в C нет (или не было до C99) ключевого слова const, поэтому, если вы хотите передать константный объект функции C, константу придется отбросить. Таким образом, стандарт C ++ определяет, что это разрешено до тех пор, пока не выполняется запись. Если функция C доступна только для чтения, константу можно безопасно отбросить.

Даже в C ++ непоследовательная или неполная константная корректность тоже довольно распространена. Поэтому иногда мы сталкиваемся с ситуациями, когда нам нужно отбросить константу, чтобы передать константный объект функции, которая не изменяет свой аргумент, а принимает его неконстантным.

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