Является ли неопределенным поведением печать нулевых указателей со спецификатором преобразования %p?
#include <stdio.h>
int main(void) {
void *p = NULL;
printf("%p", p);
return 0;
}
Вопрос относится к стандарту C, а не к реализациям C.
Это один из тех странных случаев, когда мы сталкиваемся с ограничениями английского языка и несогласованной структурой в стандарте. Так что в лучшем случае я могу привести убедительный контраргумент, поскольку это невозможно доказать :) 1
Код в вопросе демонстрирует четко определенное поведение.
Поскольку в основе вопроса лежит [7.1.4], давайте начнем с этого:
Каждое из следующих утверждений применяется, если иное явно не указано в подробных описаниях, которые следуют: Если аргумент функции имеет недопустимое значение (например, значение вне домена функции или указатель вне адресное пространство программы, или нулевой указатель, [... другие примеры ...]) [...] поведение не определено. [... другие утверждения ...]
Это корявый язык. Одна интерпретация состоит в том, что элементы в списке являются UB для всех функций библиотеки, если они не отменены отдельными описаниями. Но список начинается с «таких как», что указывает на то, что он иллюстративный, а не исчерпывающий. Например, в нем не упоминается правильное завершение строк нулевым символом (критично для поведения, например, strcpy).
Таким образом, ясно, что цель / область действия 7.1.4 просто состоит в том, что «недопустимое значение» ведет к UB (, если не указано иное). Мы должны изучить описание каждой функции, чтобы определить, что считается «недопустимым значением».
strcpy[7.21.2.3] говорит только следующее:
Функция
strcpyкопирует строку, на которую указываетs2(включая завершающий нулевой символ), в массив, на который указываетs1. Если копирование происходит между перекрывающимися объектами, поведение не определено.
В нем нет явного упоминания нулевых указателей, но и нет упоминания о нулевых терминаторах. Вместо этого из «строки, на которую указывает s2» делается вывод, что единственными допустимыми значениями являются строки (т. Е. Указатели на массивы символов с завершающим нулем).
Действительно, эту закономерность можно увидеть в отдельных описаниях. Еще несколько примеров:
# P11 #
# P12 #
# P13 #
printf[7.19.6.1] говорит следующее о %p:
p- аргумент должен быть указателем наvoid. Значение указателя преобразуется в последовательность печатаемых символов способом, определяемым реализацией.
Null - это допустимое значение указателя, и в этом разделе не упоминается явно ни то, что null - это особый случай, ни то, что указатель должен указывать на объект. Таким образом определяется поведение.
1. Если не будет заявлен автор стандартов или если мы не найдем что-то похожее на обоснование, разъясняющий ситуацию.
§7.1.4 p1 говорится: Каждое из следующих утверждений применяется, если явно не указано иное в подробных описаниях, которые следуют
- person Dror K.; 10.07.2017
§7.24.1 p2 больше не подходит: pointer arguments on such a call shall still have valid values, as described in 7.1.4.
- person Dror K.; 10.07.2017
§7.1.4 p1 в качестве ответа и не выдал TC для C99. Таким образом, интерпретация, согласно которой §7.1.4 p1 не указывает, что считается недействительным, не согласуется с их ответом и не согласуется с утверждениями в: §7.24.1 p2, §7.22.5 p1, §7.29.4 p2.
- person Dror K.; 10.07.2017
Да. Печать нулевых указателей со спецификатором преобразования %p имеет неопределенное поведение. Сказав это, я не знаю ни одной существующей соответствующей реализации, которая могла бы вести себя неправильно.
Ответ относится к любому из стандартов C (C89 / C99 / C11).
Спецификатор преобразования %p ожидает аргумент типа указатель на void, преобразование указателя в печатаемые символы определяется реализацией. Это не говорит о том, что ожидается нулевой указатель.
Во введении к функциям стандартной библиотеки говорится, что нулевые указатели в качестве аргументов функций (стандартной библиотеки) считаются недопустимыми значениями, если явно не указано иное.
C99 / C11 §7.1.4 p1
[...] Если аргумент функции имеет недопустимое значение (например, [...] нулевой указатель, [...] поведение не определено.
Примеры для функций (стандартной библиотеки), которые ожидают нулевые указатели как допустимые аргументы:
fflush() использует нулевой указатель для очистки «всех потоков» (которые применяются).freopen() использует нулевой указатель для указания файла, «связанного в данный момент» с потоком.snprintf() позволяет передавать нулевой указатель, когда n равно нулю.realloc() использует нулевой указатель для выделения нового объекта.free() позволяет передавать нулевой указатель.strtok() использует нулевой указатель для последующих вызовов.Если мы возьмем случай для snprintf(), имеет смысл разрешить передачу нулевого указателя, когда 'n' равно нулю, но это не относится к другим функциям (стандартной библиотеке), которые допускают аналогичный нулевой 'n'. Например: memcpy(), memmove(), strncpy(), memset(), memcmp().
Это не только указано во введении к стандартной библиотеке, но также еще раз во введении к этим функциям:
C99 §7.21.1 p2 / C11 §7.24.1 p2
Если аргумент, объявленный как
size_tn, определяет длину массива для функции, n может иметь нулевое значение при вызове этой функции. Если иное явно не указано в описании конкретной функции в этом подпункте, аргументы указателя при таком вызове должны по-прежнему иметь допустимые значения, как описано в п. 7.1.4.
Я не знаю, является ли UB %p с нулевым указателем на самом деле намеренным, но поскольку в стандарте явно указано, что нулевые указатели считаются недопустимыми значениями в качестве аргументов стандартных библиотечных функций, а затем он идет и явно указывает случаи, когда нулевой указатель является допустимым аргументом (snprintf, free и т. д.), а затем он идет и еще раз повторяет требование, чтобы аргументы были действительными даже в нулевых случаях n (memcpy, memmove, memset), тогда я думаю, что это разумно предположить, что комитет по стандартам C не слишком озабочен тем, чтобы такие вещи оставались неопределенными.
size_t аргументами (что и относится к такому вызову). Наша попытка печати нулевого указателя не является таким вызовом, и недопустимо обобщать правила для этих конкретных вызовов на любую функцию, принимающую указатель.
- person Jeroen Mostert; 09.07.2017
printf с недопустимым указателем в стеке, а затем ... бац.
- person Damon; 10.07.2017
%p не должна быть неопределенным поведением.
- person M.M; 14.07.2017
%p определяется реализацией для ненулевых значений, и реализация может удовлетворять требованиям документации, даже если в ней указан способ преобразования, который приведет к непредсказуемому поведению для некоторых или всех таких значений. Любая реализация, которая соответствовала бы, если бы использование %p с нулевым указателем было UB, могла бы быть выполнена соответствующей, даже если бы такое действие было IDB, просто имея в своей документации способ преобразования, который привел бы к непредсказуемому поведению при задании нулевого указателя. Отнесение поведения к IDB ничего не изменит.
- person supercat; 16.10.2018
Авторы стандарта C не приложили усилий, чтобы исчерпывающе перечислить все поведенческие требования, которым должна соответствовать реализация, чтобы соответствовать какой-либо конкретной цели. Вместо этого они ожидали, что люди, пишущие компиляторы, будут проявлять определенную долю здравого смысла независимо от того, требует этого Стандарт или нет.
Вопрос о том, вызывает ли что-то UB, редко бывает полезен сам по себе. Настоящие важные вопросы:
Должен ли кто-то, кто пытается написать качественный компилятор, заставить его вести себя предсказуемым образом? Для описанного сценария ответ однозначно положительный.
Должны ли программисты иметь право ожидать, что качественные компиляторы для чего-либо, напоминающего обычные платформы, будут вести себя предсказуемым образом? В описанном сценарии я бы сказал, что да.
Могут ли некоторые тупые авторы компиляторов растянуть интерпретацию Стандарта, чтобы оправдать совершение чего-то странного? Надеюсь, что нет, но не исключаю.
Должны ли дезинфицирующие компиляторы кричать о поведении? Это будет зависеть от уровня паранойи пользователей; дезинфицирующий компилятор, вероятно, не должен по умолчанию кричать о таком поведении, но, возможно, должен предоставить возможность конфигурации на случай, если программы могут быть перенесены на "умные" / глупые компиляторы, которые ведут себя странно.
Если разумная интерпретация Стандарта подразумевает, что поведение определено, но некоторые разработчики компиляторов растягивают интерпретацию, чтобы оправдать иное, имеет ли значение, что говорится в Стандарте?
printf("%p", (void*) 0) поведение undefined или нет, согласно Стандарту? Вызов глубоко вложенных функций так же важен для этого, как и цена чая в Китае. И да, UB очень часто встречается в реальных программах - что из этого?
- person Jeroen Mostert; 10.07.2017
%p для каждого возможного значения вопроса.
- person supercat; 10.07.2017
