C - совместимый со стандартом способ доступа к адресу нулевого указателя?

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

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ
Я абсолютный новичок, 90% или более того, что я написал, неверно, не имеет смысла или может сломать тостер. Я также пытаюсь обосновать стандарт, часто с катастрофическими и наивными результатами (как указано в комментарии).
Не читайте.
Проконсультируйтесь с @Olaf, чтобы получить официальный и профессиональный ответ.

В дальнейшем термин архитектурный адрес обозначает адрес памяти, который видит процессор (логический, виртуальный, линейный, физический или шинный). Другими словами, адреса, которые вы бы использовали при сборке.

В разделе 6.3.2.3. это читается

Целочисленное постоянное выражение со значением 0 или такое выражение, приведенное к типу void *, называется константой нулевого указателя. Если константа нулевого указателя преобразуется в тип указателя, результирующий указатель, называемый нулевым указателем, гарантированно не будет сравниваться с указателем на любой объект или функцию.

и относительно преобразования целого числа в указатель

Целое число можно преобразовать в любой тип указателя. За исключением случаев, указанных ранее [т.е. для случая константы нулевого указателя], результат определяется реализацией, может быть неправильно выровнен, может не указывать на сущность указанного типа и может быть представлением ловушки ^†.

Это подразумевает, что компилятору, чтобы быть совместимым, нужно только реализовать функцию int2ptr от целого числа до указателей, которые

1. int2ptr (0) по определению является нулевым указателем.
   Обратите внимание, что int2ptr (0) не обязательно равняется 0. Это может быть любое битовое представление.
2. * int2ptr (n! = 0) не имеет ограничений.
   Обратите внимание, что это означает, что int2ptr не обязательно должна быть функцией идентификации или функцией, возвращающей действительные указатели !

Учитывая приведенный ниже код

char* p = (char*)241;

Стандарт не дает никаких гарантий, что выражение *p = 56; будет записывать по архитектурному адресу 241.
И поэтому он не дает прямого доступа к любому другому архитектурному адресу (включая int2ptr (0), адрес, созданный нулевым указателем, если он действителен).

Проще говоря, стандарт касается не архитектурных адресов, а указателей, их сравнения, преобразований и их операций ^‡.

Когда мы пишем код типа char* p = (char*)K, мы не говорим компилятору сделать p указателем на архитектурный адрес K, мы говорим ему сделать указатель из целого числа K, или, другими словами, чтобы p указывал на (C аннотация) адрес K.

Нулевой указатель и (архитектурный) адрес 0x0 - это не одно и то же (цит.), и это верно для любого другого указателя, созданного из целого числа K и (архитектурного) адреса. К.

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

Ответ на мой собственный вопрос прост: Нет стандартного способа, потому что в стандартном документе C нет (архитектурного) адреса. Это верно для любого (архитектурного) адреса, а не только для int2ptr (0) одного ¹.

Примечание о return *(volatile char*)0;

В стандарте сказано, что

Если указателю присвоено недопустимое значение [значение нулевого указателя является недопустимым], поведение унарного оператора * не определено.

и это

Следовательно, любое выражение, относящееся к такому объекту [volatile], должно оцениваться строго в соответствии с правилами абстрактной машины.

Абстрактная машина говорит, что * не определено для значений нулевого указателя, поэтому этот код не должен отличаться от этого

return *(char*)0;

который также не определен.
На самом деле они не отличаются, по крайней мере, с GCC 4.9, оба компилируются в соответствии с инструкциями, указанными в моем вопросе.

Определяемый реализацией способ доступа к архитектурному адресу 0 для GCC - это использование флага -fno-isolate-erroneous-paths-dereference, который производит "ожидаемый" ассемблерный код.

_{^† Функции преобразования для преобразования указателя в целое число или целого числа в указатель предназначены для согласования со структурой адресации среды выполнения.}

_{^‡ К сожалению, он говорит, что & дает адрес своего операнда, я считаю, что это немного неправильно, я бы сказал, что он дает указатель на свой операнд. Рассмотрим переменную a, которая, как известно, находится по адресу 0xf1 в 16-битном адресном пространстве, и рассмотрим компилятор, который реализует int2ptr (n) = 0x8000 | п. &a даст указатель с битовым представлением 0x80f1, который не является адресом a.}

_{¹ Что было особенным для меня, потому что в моих реализациях он был единственным, к которому нельзя было получить доступ.}

Поскольку OP правильно заключила в своем ответе на свой вопрос:

Стандартного способа нет, потому что в стандартном документе C нет (архитектурного) адреса. Это верно для любого (архитектурного) адреса, а не только для int2ptr (0).

Однако ситуация, когда кто-то захочет получить доступ к памяти напрямую, скорее всего, будет использоваться с использованием настраиваемого сценария компоновщика. (То есть что-то вроде встроенных систем.) Итак, я бы сказал, что стандартный совместимый способ сделать то, что запрашивает OP, - это экспортировать символ для (архитектурного) адреса в скрипт компоновщика, а не беспокоиться о точном адресе в Сам код на C.

Вариантом этой схемы было бы определение символа по нулевому адресу и простое использование его для получения любого другого необходимого адреса. Для этого добавьте что-то вроде следующего в SECTIONS часть скрипта компоновщика (при условии синтаксиса GNU ld):

_memory = 0;

А затем в вашем коде C:

extern char _memory[];

Теперь можно, например, создать указатель на нулевой адрес, используя, например, char *p = &_memory[0]; (или просто char *p = _memory;), никогда не преобразовывая int в указатель. Точно так же int addr = ...; char *p_addr = &_memory[addr]; создаст указатель на адрес addr без технического преобразования int в указатель.

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

Какое бы решение ни зависело от реализации. Надо. ISO C не описывает среду, в которой работают программы на языке C; скорее, как выглядит соответствующая программа на языке C в различных средах («системах обработки данных»). Стандарт действительно не может гарантировать того, что вы получите, обратившись к адресу, который не является массивом объектов, то есть чем-то, что вы явно выделяете, а не среде.

Поэтому я бы использовал то, что стандарт оставляет как определяемое реализацией (и даже как условно поддерживаемое), а не неопределенное поведение *: Встроенная сборка. Для GCC / clang:

asm volatile("movzx 0, %%eax;") // *(int*)0;

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

§ 5.1.2

Определены две среды выполнения: автономная и размещенная. [...]

§ 5.1.2.1, запятая 1

В автономной среде (в которой выполнение программы C может происходить без каких-либо преимуществ операционной системы) имя и тип функции, вызываемой при запуске программы, определяются реализацией. Любые библиотечные средства, доступные для автономной программы, кроме минимального набора, требуемого разделом 4, определяются реализацией. [...]

Обратите внимание, это не говорит о том, что вы можете получить доступ к любому адресу по своему желанию.

^{Что бы это ни значило. Все обстоит немного иначе, когда вы являетесь реализацией, которой управляют стандартные делегаты.}

^{Все цитаты взяты из черновика № 1570.}

Стандарт C не требует, чтобы реализации имели адреса, которые по форме или форме напоминали целые числа; все, что для этого требуется, - это то, что если типы uintptr_t и intptr_t существуют, преобразование указателя в uintptr_t или intptr_t даст число, а преобразование этого числа непосредственно обратно в тот же тип, что и исходный указатель, даст указатель, равный исходному.

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

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

*((uint32_t volatile*)0) = 0x12345678;
*((uint32_t volatile*)x) = 0x12345678;

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

Я предполагаю, что вы задаете вопрос:

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

Согласно дословному прочтению Стандарта, это невозможно. 6.3.2.3/3 говорит, что любой указатель на объект должен быть не равен нулевому указателю.

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

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

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