Оценка выражения в printf с помощью %p

Нет никакой гарантии, что так и будет. Как говорится, это наиболее вероятный результат. b имеет значение 30, которое в шестнадцатеричном формате равно 0x1e. Приведение к size_t этого не меняет. Приведение к void * просто создает указатель на это значение, которое на вашей платформе и значение 30 сохраняет это значение как указатель. Итак, у вас получился указатель void * со значением 30 или 0x1e. Чего вы ожидали от этого?

Я ожидал ошибки, потому что я использую «b» вместо «&b».

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

Выражение (void *)(size_t)b уже является неопределённым поведением в Стандарте C, если только по этому адресу не существует допустимый объект. Конкретные платформы могут определять поведение

@M.M Насколько я понимаю, приведение целого числа к void * не является неопределенным поведением. (Если бы это было так, у нас были бы проблемы с #define NULL (void *)0.) Если я ошибаюсь, мне было бы интересно, из какой части стандарта вы взяли это утверждение.

UB оценивает результат выражения. Значение указателя при оценке должно указывать на действительный объект или на ноль (примечание: я намеренно говорю «оцененный», а не «разыменованный»)

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

@M.M Мне все равно хотелось бы узнать об этом главу и стих, если бы вы могли их дать, потому что я знаю несколько систем, которые их используют (например, во время ранней загрузки).

C11 6.3.2.3/5 — результатом этого преобразования может быть представление ловушки (которое определено в 6.2.6.1/5).

@M.M Преобразование целого числа в указатель - это не UB. Вы получаете UB только в том случае, если результатом преобразования является представление ловушки, а затем считывается значение lvalue, в котором хранится результат.

@dbush Результат считывается (оценивается выражение), передавая его в printf. Кроме того, результат приведения никогда не является lvalue.

@M.M Приведение не является lvalue, а параметром, данным функции (по крайней мере, если это не параметр с переменным числом аргументов, а если это так, я не уверен).

@M.M Ах, теперь я понял. Я имел в виду действительные физические адреса для MMIO, за исключением произвольных, как здесь. Спасибо за разъяснения.

@DevSolar Не могли бы вы отредактировать свой ответ с учетом этого обсуждения? Я думаю, это ответ на мой вопрос. Всем спасибо.

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

@newbie Подожди... ты ожидал предупреждения для актеров? В этом случае знайте, что приведения в стиле C ((typename)) — это то, что в C++ называется reinterpret_cast. Нет никакой проверки работоспособности ни по типу, ни по размеру, ни по содержимому. Обращаться осторожно. ;-)

@DevSolar Да, я ожидал предупреждения, которое превратилось в ошибку из-за флага -Werror. Благодаря всем комментариям здесь и в моем вопросе мне удалось немного лучше понять ситуацию, но не до конца. У меня были неправильные представления о приведении типов и назначении указателей, хотя, честно говоря, эта часть о UB от меня ускользнула.

@newbie На самом деле это следствие. Очевидно, что «жесткое приведение» некоторого «случайного» целочисленного значения, которое не должно быть указателем, в указатель - это катастрофа, ожидающая своего часа. Мы с М.М обсуждали, в какой момент именно было выполнено действие — при разыменовании («использовании») указателя (чего ваша программа не делает) или уже при его приведении и передаче в printf. Если вас интересует мелкий шрифт, задайте новый вопрос (после проверки того, что на него уже нет ответа).