Переменные-указатели - это просто целые числа с некоторыми операторами или они являются символическими?

C был задуман как язык, в котором указатели и целые числа были очень тесно связаны, причем точное соотношение зависело от целевой платформы. Связь между указателями и целыми числами сделала язык очень подходящим для целей низкоуровневого или системного программирования. Поэтому для целей обсуждения ниже я назову этот язык «Низкоуровневый C» [LLC].

Комитет по стандартам C написал описание другого языка, где такие отношения прямо не запрещены, но не признаются каким-либо полезным образом, даже когда реализация генерирует код для поля цели и приложения. где такие отношения были бы полезны. Я назову этот язык «Только высокий уровень C» [HLOC].

В те дни, когда был написан Стандарт, большинство вещей, которые называли себя реализациями C, обрабатывали диалект LLC. Большинство полезных компиляторов обрабатывают диалект, который определяет полезную семантику в большем количестве случаев, чем HLOC, но не так много, как LLC. Будут ли указатели вести себя больше как целые числа или как абстрактные мистические сущности, зависит от того, какой именно диалект используется. Если кто-то занимается системным программированием, разумно рассматривать C как обрабатывающий указатели и целые числа как тесно связанные, потому что диалекты LLC, подходящие для этой цели, делают это, а диалекты HLOC, которые этого не делают, не подходят для этой цели. Однако при выполнении высокопроизводительного вычисления чисел гораздо чаще используются диалекты HLOC, которые не распознают такую ​​взаимосвязь.

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

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

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

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

Например, я писал код в системе 6809, где половина памяти выгружалась через PIA, адресуемую в невыгружаемой части карты памяти. Мой компилятор c смог справиться с этим, потому что указатели для этого компилятора были «мистическим» типом, который знал, как писать в PIA.

Семейство 80386 имеет режим адресации, при котором адреса организованы в группы по 16 байтов. Посмотрите FAR указатели, и вы увидите другую арифметику указателей.

Это история развития указателей в C ++. Не все производители микросхем ведут себя «хорошо», и язык позволяет их всех (обычно) без необходимости переписывать исходный код.

Похищение цитаты из TartanLlama:

[expr.add] / 5 "[для добавления указателя,] если и операнд-указатель, и результат указывают на элементы одного и того же объекта массива или на один за последним элементом объекта массива, оценка не должна вызывать переполнения; в противном случае поведение не определено. "

Таким образом, компилятор может предположить, что ваш указатель указывает на массив a или на один за концом. Если он указывает кому-то за конец, вы не можете отнестись к нему с уважением. Но, как вы это делаете, он, конечно же, не может быть дальше конца, поэтому он может быть только внутри массива.

Итак, теперь у вас есть код (сокращенный)

b = 1;
*pa1 = 2;

где pa указывает внутри массива a, а b - отдельная переменная. И когда вы их распечатываете, вы получаете точно 1 и 2, значения, которые вы им присвоили.

Оптимизирующий компилятор может понять это, даже не сохраняя 1 или 2 в памяти. Он может просто распечатать окончательный результат.

Если вы выключите оптимизатор, код работает должным образом.

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

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

Изменить:

Пересмотренный код по-прежнему UB. Стандарт не позволяет ссылаться на a[1], даже если значение указателя совпадает с другим значением указателя. Таким образом, оптимизатору разрешено сохранять значение b в регистре.