Изменение констант базовых типов

Question

Хотелось бы понять, как С++ обрабатывает константы базовых типов.

Что будет, если при помощи плясок с бубном и указателями изменить значение, находящееся в ячейке памяти, где, по идее, и должна содержаться константа?

Есть следующий код:

#include <iostream>

using namespace std;

int main(int argc, char** argv) {
    const int number = 45;
    const int * constPoint = &number;
    cout << "constPoint " << constPoint << endl;
    int * point = (int *) constPoint;
    cout << "     point " << point << endl;
    * point = 54;
    cout << "&number " << &number << "; number " << number << endl;
    cout << "  point " << point   << "; *point " << *point << endl;
}

Вывод у меня получается следующий:

constPoint 0x7fff1b73a6ec
     point 0x7fff1b73a6ec
&number 0x7fff1b73a6ec; number 45
  point 0x7fff1b73a6ec; *point 54

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

Как объяснить подобное поведение?

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

Answer 1

Для начала: по стандарту, изменение при помощи трюков с указателями констант есть undefined behaviour. Может случится всё, что угодно в любой точке программы.

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

Например, если компилятор видит обращение к константе, он может встроить её в точку вызова (он ведь знает значение на этапе компиляции), может обратиться к этой константе по адресу в любой момент, может даже выразить другие константы через эту (например, если у вас есть константа 1024, то обращение к 2048 он имеет право представить как 1024 << 1 из соображений эффективности).

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

На UB обычно основаны дыры в безопасности программ. Например, если компилятор обоснованно считает, что длина строки 45, и под неё достаточно выделить буфер такой длины, в то время как вы, обманув компилятор, подсунете ему строку длиной 54, получится классический срыв стека.

---

Резюме: У компилятора нет никаких «обязательств» или «принципов» по работе с константами. Он имеет право делать что угодно. Наоборот, это программист, если уж обещал, что какое-то значение есть константа, не имеет права его менять.

Answer 2

Согласно стандарту C++ (7.1.6.1 The cv-qualifiers)

4 Except that any class member declared mutable (7.1.1) can be modified, any attempt to modify a const object during its lifetime (3.8) results in undefined behavior

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

В C++ строковые литералы имеют типы константных символьных массивов. Например, строковый литерал "Hello" имеет тип const char[6]. Однако в C строковые литералы имеют типы неконстантных символьных массивов. Поэтому этот же самый строковый литерал "Hello" в C имеет тип char[6]. Тем не менее вы не можете изменить строковый литерал в C, также как вы не можете изменить строковый литерал в C++.

Из стандарта C (6.4.5 String literals)

7 It is unspecified whether these arrays are distinct provided their elements have the appropriate values. If the program attempts to modify such an array, the behavior is undefined.

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

Answer 3

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

volatile const int number = 45;

Полный код: http://codepad.org/tNlZoNkE
Вариант с кастом в void* для вывода: http://codepad.org/EoqOgd6t

PS: Насколько я помню, volatile const это корректная ситуация, которая не должна приводить к undefined behavior.

он имеет полное право предполагать, что свой код точно не меняет const-объекты.

Для volatile это неважно. Представим, что есть нечто внешнее, что "совершенно случайно" меняет ту же константу на те же значения, что мы написали. А в самой программе вместо изменяющего кода стоят nop'ы. Такой вариант абсолютно точно корректен и не вызывает UB.

Значит, если UB есть, то его вызывает не изменившееся значение, а сама операция записи. Есть ли какой-то случай, в котором это возможно? Приходит в голову только read-only страница в памяти, но может ли компилятор так поступить? Локальную переменную он поместит в стек, который однозначно не readonly. Остаются глобальные. (Поля объектов попадают в одну из этих категорий.) Или есть ещё ситуации, когда операция записи может что-то испортить?