Удаляет ли const const из указателя-в-const строгое сглаживание в C и ссылается на тот же объект?

Определяет ли следующий код в C?

int main() {
    const int i = 0;
    return *(int*)(&i);
}

Я спрашиваю, потому что 6.5/7 перечисляет "квалифицированную версию типа, совместимую с эффективным типом объекта" как действительный псевдоним. Но эффективный тип объекта const int, и я не думаю, что int - это квалифицированная версия const int (хотя верно обратное). Не совместимы int и const int (6.7.3/10).

Кроме того, в 6.3.2.3/2 говорится, что вы можете преобразовывать типы указателей, добавляя квалификаторы, и что полученный указатель равен. 6.3.2.3/7 говорит, что вы можете конвертировать любые два типа указателей (поэтому разрешен листинг (int*)(&i)). Но не говорит, что полученный указатель относится к одному и тому же объекту или даже к тому, что он равен. Все, что он говорит, это то, что он может быть преобразован обратно в исходный тип (в данном случае const int*). То есть, даже если псевдоним легален, мне не ясно, что стандарт гарантирует, что мое преобразование указателя действительно приведет к указателю, который ссылается на i.

Итак, действительно ли стандарт определяет поведение моего кода, и если да, то где это определено?

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

Ответы

Ответ 1

По крайней мере, подразумевается, что он работает, в соответствии с §6.7.3 p5:

Если сделана попытка изменить объект, определенный с помощью const-квалифицированный тип с использованием lvalue с неконстантно-квалифицированными тип, поведение undefined. Если делается попытка сослаться на объект, определенный с помощью нестабильного типа, с использованием значения lvalue с типом энергонезависимого типа, поведение undefined.

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

Мне кажется, что вы, возможно, идентифицировали дефект в стандарте.