Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > C/C++: Для новичков > Разыменовывание нулевого указателя приводит к неопределённому поведению


Автор: Thunderbolt 17.2.2015, 10:11
Напомню историю обсуждений

Все началось со http://www.viva64.com/ru/b/0299/ о проверке ядра Linux с помощью анализатора PVS-Studio. Но сама проверка ядра тут ни причём. Дело в том, что в статье я привёл следующий фрагмент из кода Linux:

Код
static int podhd_try_init(struct usb_interface *interface,
        struct usb_line6_podhd *podhd)
{
  int err;
  struct usb_line6 *line6 = &podhd->line6;

  if ((interface == NULL) || (podhd == NULL))
    return -ENODEV;
  ....
}


Я назвал этот код опасным, так как посчитал, что здесь имеет место http://www.viva64.com/ru/t/0066/. 

По этому поводу я получил много возражений от читателей и даже одно время был готов поддаться на их убедительные речи в письмах и комментариях. Например, в качестве доказательства корректности кода приводили устройство макроса http://www.viva64.com/go.php?url=1481, который часто реализован так:

Код
#define offsetof(st, m) ((size_t)(&((st *)0)->m))


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

Хотя я и доверчивый, но стараюсь проверять информацию. Я начал разбираться с этой темой и в результате написал небольшую статью: "http://www.viva64.com/ru/b/0301/".

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

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


О языке Си

Выражение '&podhd->line6' является неопределенным поведением в языке C в том случае, если 'podhd' - нулевой указатель.

Вот что говорится про оператор взятия адреса '&' в стандарте C99 (Раздел 6.5.3.2 "Операторы взятия адреса и разыменовывания"):

Операнд унарного оператора & должен быть либо указателем функции, либо результатом оператора [] или унарного оператора *, либо lvalue-выражением, указывающим на объект, который не является битовым полем и не содержит в объявлении спецификатора регистрового класса памяти.

Выражение 'podhd->line6' однозначно не является указателем функции, результатом оператора [] или *.  Это как раз lvalue-выражение. Однако, когда указатель 'podhd' равен нулю, выражение не указывает на объект, поскольку в Разделе 6.3.2.3 "Указатели" сказано следующее:

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

Если "lvalue-выражение не указывает на объект при своем вычислении, возникает неопределенное поведение" (Стандарт C99, Раздел 6.3.2.1 "Lvalue-выражения, массивы и указатели функций"):

lvalue - это выражение объектного типа или неполного типа, отличного от void; если lvalue-выражение не указывает на объект при своем вычислении, возникает неопределенное поведение.

Ещё раз кратко:

Когда оператор -> был применен к указателю, его результатом стало lvalue-выражение, для которого не существует объекта, и в результате мы имеем дело с неопределенным поведением.


О языке Си++

В языке С++ всё обстоит точно также. Выражение '&podhd->line6' является неопределенным поведением в языке C++ в том случае, если 'podhd' - нулевой указатель.

С толку немного сбивает дискуссия на WG21 (http://www.viva64.com/go.php?url=1484), на которую я ссылался в предыдущей статье. Там настаивают, будто бы такое выражение не является неопределенным поведением. Однако никто так и не нашел никаких правил в стандартах C++, которые разрешали бы использовать "poldh->line6", когда "polhd" - нулевой указатель.

Указатель "polhd" нарушает основное ограничение (Раздел 5.2.5/4, второй пункт в списке) о том, что он должен указывать на объект. Ни один объект в C++ не может иметь адреса nullptr.


Итого

Код
struct usb_line6 *line6 = &podhd->line6;


Этот код является некорректным в языке Си и Си++, если указатель podhd равен 0. Если указатель равен 0, то возникает неопределённое поведение.

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

Так писать нельзя. Указатель должен быть проверен до разыменования.


Разное в дополнение
  • При рассмотрении идиоматической реализации http://www.viva64.com/go.php?url=1481 следует учитывать, что компилятору разрешено использовать непереносимые приемы для реализации этой функциональности. Тот факт, что в реализации библиотеки в компиляторе используется константа нулевого указателя при реализации offsetof(), вовсе не означает, что в пользовательском коде можно без опаски применять '&podhd->line6' в случае, когда'podhd' является нулевым указателем.
  • GCC может (и делает это) проводить оптимизацию, основываясь на предположении, что никакого неопределенного поведения возникнуть не может, и убрать в данном случае проверки указателей на ноль - поэтому ядро компилируется с набором ключей, указывающих компилятору не делать этого. Например, эксперты в качестве примера ссылаются на статью "http://www.viva64.com/go.php?url=1499".
  • Возможно, вам также будет интересно узнать, что подобным образом нулевой указатель был задействован в эксплойте ядра с помощью TUN/TAP-драйва. Подробности можно посмотреть по ссылке "http://www.viva64.com/go.php?url=1500". Некоторые могут решить, будто эти два примера имеют мало общего, поскольку во втором случае есть существенное отличие: в баге TUN/TAP-драйвера вместо простого взятия адреса поля структуры, к которому обращался нулевой указатель, это поле было явно взято в качестве значения для инициализации переменной. Однако с точки зрения стандарта C взятие адреса поля с помощью нулевого указателя также является неопределенным поведением.
  • А есть ли какая-та ситуация, когда при P == nullptr мы напишем &P->m_foo и всё будет хорошо? Да, например это может быть аргументом оператора sizeof: sizeof(&P->m_foo).


Благодарности

В подготовке статьи мне помогли эксперты, сомневаться в компетенции, которых нет повода. Я благодарен за помощь в написании статьи следующим людям:
  • Майкл Бёрр - горячий поклонник языка C/C++ и специалист по системному и встроенному ПО, в том числе службам Windows, работе с сетями и драйверам устройств. Активно участвует в жизни сообщества http://www.viva64.com/go.php?url=1493, отвечая на вопросы программистов по C и C++ (а иногда и на некоторые простые вопросы по C#). Имеет 6 наград Microsoft MVP в номинации Visual C++.
  • Билли О'Нил- разработчик ПО на C++ (преимущественно) и активный участник сообщества http://www.viva64.com/go.php?url=1494. Является инженером-разработчиком ПО в подразделении по совершенствованию систем безопасности Microsoft (Trustworthy Computing Team). До этого работал в нескольких компаниях, занимающихся безопасностью ПО, в числе которых - Malware Bytes и PreEmptive Solutions.
  • Джованни Диканио - программист, специализирующийся на разработке ОС Windows. Автор статей для программистов по C++, OpenGL и другим темам в ряде итальянских компьютерных журналов. Также писал код для некоторых открытых проектов. Джованни помогает коллегам, давая советы по решению программистских проблем, связанных с C и C++, на форумах http://www.viva64.com/go.php?url=1495, а с некоторых пор - и на StackOverflow. Имеет 8 наград Microsoft MVP в номинации Visual C++.
  • Габриэль Дус Рейс - главный инженер-разработчик ПО Microsoft. Также является исследователем и долгосрочным участником C++-сообщества. Одно из направлений его научных интересов и исследований - средства разработки надежного ПО. До того, как прийти в Microsoft, работал старшим преподавателем в Техасском Университете A&M (Texas A&M University). В 2012 году Доктор Дус Рейс был отмечен премией Национального Научного Фонда (National Science Foundation CAREER Award) за проведенное им исследование компиляторов надежного ПО в области вычислительной математики и за образовательную деятельность. Является членом комитета по стандартизации языка C++.


Дополнительные ссылки
  1. Wikipedia. http://www.viva64.com/go.php?url=1496.
  2. A Guide to Undefined Behavior in C and C++. Part http://www.viva64.com/go.php?url=750, http://www.viva64.com/go.php?url=1497, http://www.viva64.com/go.php?url=1498.
  3. Wikipedia. http://www.viva64.com/go.php?url=1481.
  4. LLVM Blog. http://www.viva64.com/go.php?url=1499.
  5. LWN. Fun with NULL pointers. Part http://www.viva64.com/go.php?url=1500, http://www.viva64.com/go.php?url=1501.

Автор: TarasProger 12.8.2015, 19:56
Разыменование нулевого указателя и не должно быть ни безопасным, ни определённым. Взять хотыбы этот код из стартового поста: 
Код
struct usb_line6 *line6 = &podhd->line6;
. С одной стороны доступ по указателю не происходит, а происходит вычисление смещённого адреса и присвивание его другому указателю, что вполне можно сделать, сложив значение нулевого указателя со смещением. Но с другой строны этот смщённый адрес по семантике данного кода является адресом поля не существующей структуры, соотвественно рузультат должен быть нулевым указателем. С третьей доступ по указателю всё таки имеет место: 
Код
struct usb_line6 *line6 = &(podhd->line6);
, что вообще должно вызвать фатальную ошибку программы. Адекватно разрулить это нельзя вне зависимости от того, что на этот случай напишут в стандарте. А потому даже если поведение компиляторов в данном случае сейчас определено, нельзя полагаться на то, что оно таким и останется в следующих версиях стандарта. А соответственно и на то, что поведение компиляторов не поменяется в будущем на какое нибудь сейчас не известное.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)