Итак, мне интересно, есть ли хороший маркер для выбора в C, кроме общего 0xDEADBEEF или менее привлекательного (для правильного кода) 0x0BADA550.Что выбрать как хороший маркер в C?
Ваш любимый? Есть ли какая-нибудь причина для выбора того или иного значения?
Википедия имеет whole page по этому вопросу; он предоставляет множество примеров и известных программ, в которых они используются.
В любом случае, если вы работаете над x86, вы должны рассмотреть следующее предложение @ torak, память, заполненную int 3, меня несколько раз спасла. Если вы чувствуете себя творчески, вы можете сделать его более узнаваемым и использовать CC90CC90, что переводится в чередующиеся int 3 и nop.
0xBABECAFE, 0xBADADD00, 0xBADBAD00, 0xFADEFADE
0xCAFEBABE, я понимаю, магическое число для Java. Единственное, что делает лучше, чем другое, - это то, насколько маловероятно, чтобы оно появлялось в данных или в неинициализированной памяти. Поэтому не используйте 0x00000000 или все F s.
Это зависит от того, что вы пытаетесь отметить. Например, вам нужно различать выделенную, но неинициализированную память и освобожденную память? Если это так, вам нужны разные маркеры для этих двух.
Единственный маркер, который я могу придумать, может иметь более чем эстетическое значение: 0xCCCCCCCC. Если с помощью какой-либо ошибки он был выполнен, то 0xCC переводится в инструкцию INT 3.
Это будет работать в IA-32 и x86-64. Я не уверен, существуют ли эквиваленты для других архитектур.
... на x86 (?) Машинах ... – dmckee
@dmckee: Ах, да. Я добавлю это. Спасибо! – torak
Я думаю, что 0xCCCCCCCC имеет дополнительное преимущество в том, что он обычно указывает на пространство виртуальной памяти ядра, попытка использовать такой указатель из пользовательского пространства приведет к сбою приложения (что отлично подходит для отладки). –
Ну, я всегда выбрал 0x80000000, 0x80000001, увеличивая для каждого нового типа региона щекотку неожиданных значений со знаками целых чисел. Использование этих значений будет необычайно большим для неподписанных типов, в основном отрицательных для подписанных типов, и внезапно становится положительным для любых вычитаний (тем самым одновременно проверяя другие ошибки). У этого есть другой аккуратный побочный эффект, поскольку различные биты ALU будут установлены таким образом, как переполнение, которое может быть обнаружено с использованием -ftrapv и других флагов компилятора.
У каждого свои предпочтения. Если каждый в команде использует другой маркер, он может помочь определить источник ошибки. Как в:
«DEADBEEF? О, это должно быть от кода Джона».
Возможный дубликат [Памятное 32-битное значение как константа] (http://stackoverflow.com/questions/1810529/memorable-32-bit-value-as-a-constant) –
Для меня это не было чтобы закрыть, как сказано в разных ответах, такие значения выбираются не только для эстетики и узнаваемости, но и для какой-то функциональности (см. материал int 3). –