0xDEADBEEF эквивалент для 64-битной разработки?

Question

Для разработки на C ++ для 32-битных систем (будь то Linux, Mac OS или Windows, PowerPC или x86) Я инициализировал указатели, которые в противном случае будет неопределенным (например, они не могут сразу получить правильное значение) вроде так:

int *pInt = reinterpret_cast<int *>(0xDEADBEEF);

(Чтобы сохранить набор текста и значение DRY , правая сторона обычно быть в константе, например BAD_PTR.)

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

Конечно, поведение зависит от основных аппаратное обеспечение (получение 4-байтового целого числа из нечетного адрес 0xDEADBEEF от пользовательского процесса может быть идеально действителен), но сбой был на 100% надежным для всех системы, которые я разработал до сих пор (Mac OS 68xxx , Mac OS PowerPC, Linux Redhat Pentium, Windows GUI Pentium, Windows консоль Pentium). Например, на PowerPC это незаконно (шина ошибка) для получения 4-байтового целого числа с нечетного адреса.

Какое значение имеет это для 64-битных систем?

Answer 1

0xBADC0FFEE0DDF00D

Answer 2

Согласно Википедии , BADC0FFEE0DDF00D используется в 64-битных системах IBM RS / 6000 для индикации неинициализированных регистров ЦП.

Answer 3

Большинство современных 64-битных систем позволяют использовать только самые младшие 2 ⁴⁸ - 2 ⁵² бит адресного пространства; старшие биты адреса должны быть все ноль. Некоторые чипы (например, amd64) также позволяют использовать наивысший 2 ⁴⁸ - 2 ⁵² . Адреса за пределами этих диапазонов никогда не могут быть сопоставлены с доступной памятью; аппаратное обеспечение просто не позволит этого.

Поэтому я рекомендую вам использовать значение, близкое к 2 ⁶³ , которое не находится ни в одном из возможных мест. Если первые четыре шестнадцатеричные цифры 7ff8, значение будет NaN с плавающей запятой двойной точности, что удобно. Поэтому моя предложенная милая шестнадцатеричная фраза - 0x7FF8BADFBADFBADF.

Кстати, вы действительно не хотите использовать значение, близкое к 0, потому что это затрудняет определение смещения разыменования NULL & mdash; доступ к элементу структуры, например & mdash; из разыменования образца яда.

Answer 4

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

Посмотрите в ядре Linux на include / linux / toxic.h . Этот файл содержит разные значения ядов для разных подсистем ядра. Не существует подходящего значения яда.

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

Answer 5

Я предполагаю, что вы уже со скидкой NULL (т. Е. 0 без Typecast). Это определенно самый безопасный выбор, поскольку теоретически действительный указатель может указывать на адрес памяти 0xDEADBEEF (или любой другой адрес памяти, отличный от NULL).

Answer 6

0xDEADBEEFBAADF00D может работать.

Answer 7

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

Answer 8

Два 0xDEADBEEF должно быть достаточно, я думаю ..

Answer 9

Я вижу несколько ответов, утверждающих, что NULL - хороший выбор, но я не согласен.

NULL часто используется как допустимое возвращаемое значение из функций. Это указывает на возврат ошибки или неизвестное значение. Это другое значение, чем «неинициализированный указатель».

Использование отладчика в коде и просмотр значения NULL оставят две возможности: указатель никогда не инициализируется или ему не удалось выделить память.

Установка неинициализированного указателя на 0xDEADBEEF или 64-битный эквивалент означает, что указатель NULL указывает на преднамеренное значение.

Answer 10

Конечно, это зависит от операционной системы и среды. Я не думаю, что 0xDEADBEEF обязательно является плохим указателем в произвольной 32-битной системе.

Реально, любая современная ОС должна защищать доступ к первым нескольким страницам памяти процесса, поэтому значение NULL должно быть хорошим недопустимым указателем. Достаточно удобно, это уже предопределено для вас.