Для разработки 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-битных системах?
0
не может быть сопоставлен. В Linux легко сопоставить адрес0
, изменив параметр в ядре. В любом случае, урок, извлеченный здесь, состоит в том, чтобы не использовать глупые шаблоны для пометки указателей как недействительные, использоватьnull
или отдельный флаг в структуре. Предполагать, что он просто выйдет из строя, совершенно безответственно и невежественно, если вам повезет, вы получите только segfault, вполне вероятно, что это может привести к удаленному выполнению кода, и уже было много, много, много раз в прошлом. - person L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o   schedule 03.08.2010(void*)0
в точку, отличную от адреса 0. Однако таблица векторов прерываний не является объектом C или функцией C, поэтому я не думаю, что компиляторы обязаны гарантировать, что NULL не указывает на таблицу векторов прерываний. - person bk1e   schedule 27.04.2011