0xDEADBEEF equivalente para o desenvolvimento de 64 bits?

Question

Para o desenvolvimento de C ++ para sistemas de 32 bits (seja ele Linux, Mac OS ou Janelas, PowerPC ou x86) Eu inicializado ponteiros que de outra forma, ser definida (por exemplo, não pode imediatamente obter um valor adequado) assim:

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

(Para salvar digitação e sendo DRY lado direito normalmente estar em constante, por exemplo BAD_PTR.)

Se Pint é dereferenced antes que fique um valor adequado, em seguida, ele irá travar imediatamente na maioria dos sistemas (em vez de deixar de funcionar muito mais tarde, quando parte da memória é substituído ou ir em um tempo muito longo loop).

É claro que o comportamento depende do subjacente hardware (recebendo um inteiro de 4 byte do impar endereço 0xDEADBEEF a partir de um processo de usuário pode ser perfeitamente válido), mas a queda foi de 100% confiável para toda a sistemas que tenho desenvolvido para tão longe (Mac OS 68xxx , Mac OS PowerPC, Linux Redhat Pentium, o Windows GUI Pentium, o Windows consola Pentium). Por exemplo em PowerPC é ilegal (bus Falha) para obter um número inteiro de 4 byte de um endereço ímpar.

O que é um valor bom para isso em sistemas de 64 bits?

Answer 1

Geralmente não importa exatamente que padrão você escreve, é importante que você possa identificar o padrão, a fim de determinar onde os problemas estão ocorrendo. Acontece que no Linux Kernel estas são muitas vezes escolhidos de modo que eles podem ser presos se os endereços são dereferenced.

Tenha um olhar no kernel do Linux em include / linux / poison.h . Este arquivo contém valores diferentes de veneno para muitos subsistemas do kernel diferentes. Não há valor um veneno que é apropriado.

Além disso, você pode verificar per-arquitetura incluem arquivos no kernel Linux árvore fonte para informações sobre o que é usado em arquiteturas específicas.

Answer 2

0xBADC0FFEE0DDF00D

Answer 3

Segundo a Wikipedia , BADC0FFEE0DDF00D é usado em 6000 sistemas IBM RS / 64-bit para indicar registros de CPU não inicializadas.

Answer 4

A maioria dos sistemas atuais de 64 bits permitem que você use somente o menor 2 ⁴⁸ -2 ⁵² pedaços do espaço de endereço; os bits superiores do endereço deve ser todo-zero. Alguns chips (por exemplo amd64) também permitem que você use o maior 2 ⁴⁸ -2 ⁵² . Endereços fora destes limites não pode nunca ser mapeados para memória acessível; o hardware simplesmente não vai permitir isso.

Por isso, recomendamos que você use um valor próximo de 2 ⁶³ , que está longe de ser um dos espaços possivelmente-utilizáveis. Se os quatro dígitos hexadecimais são 7ff8, o valor será uma precisão dupla de ponto flutuante NaN, que é conveniente. Assim, a minha frase bonito hexadecimal sugerido é 0x7FF8BADFBADFBADF.

A propósito, você realmente não quiser usar um valor próximo de 0, porque isso faz com que seja difícil dizer um deslocamento dereference de NULL - um acesso membro da estrutura, por exemplo - de um dereference do padrão veneno.

Answer 5

Eu estou supondo que você já descontado NULL (ou seja, 0 sem a typecast). É definitivamente a escolha mais segura, como, em teoria, um ponteiro válido poderia apontar para o endereço de memória 0xDEADBEEF (ou qualquer outro endereço de memória não-NULL).

Answer 6

trabalho 0xDEADBEEFBAADF00D poder.

Answer 7

Eu não tenho uma boa escolha para você, mas aqui está um lista de palavras hexadecimais que você pode usar para fazer a sua frase.

Answer 8

Dois 0xDEADBEEFs deve ser o suficiente, eu acho ..

Answer 9

Eu vejo várias respostas alegando NULL é uma boa escolha, mas eu discordo.

NULL é frequentemente utilizado como um valor de retorno válido de funções. Ele indica um retorno de falha ou um valor desconhecido. Este é um significado diferente do "ponteiro não inicializado."

Usando um depurador sobre o código e vendo NULL, então, deixar duas possibilidades:. O ponteiro não foi inicializado ou ele tinha falhado uma alocação de memória

Definindo o ponteiro não inicializado para 0xDEADBEEF ou os meios equivalentes de 64-bit que um ponteiro nulo indica um valor intencional.

Answer 10

Depende do sistema operacional e do meio ambiente, é claro. Eu não acho que 0xDEADBEEF é necessariamente um ponteiro ruim em um sistema de 32 bits arbitrária, tampouco.

Na realidade, qualquer sistema operacional moderno deve ser acesso de proteger as primeiras páginas de memória do processo, de modo que NULL deve ser um bom valor de ponteiro inválido. Convenientemente o suficiente, já está pré-definido para você.

Answer 11

0x42 poderia trabalhar em ambos 32 bits e 64 bits? (Ele ainda deve provocar um acidente, uma vez que está perto o suficiente para o ponteiro NULL, e dado que é bastante grande, as chances são que você não teria que dentro de um dereference regular de um campo de estrutura com o ponteiro estrutura sendo NULL).

Answer 12

Como o sistema em que trabalhei basicamente roda em plataforma x86_64, o uso valor I é:

0xDEADBEEFDEADBEEF

As razões são:

• Na plataforma x86_64, apenas o de baixa ordem de 48 bits são usados ??para endereçamento de memória virtual na implementação atual, ou seja, qualquer valor> 2 ^ 48 deve funcionar: https://en.wikipedia.org/wiki/X86-64
• Como 0xDEADBEEF já é muito conhecido para este fim em 32 bits, 0xDEADBEEFDEADBEEF em 64bit é apenas mais 'compatível'