0xDEADBEEF équivalent pour le développement 64 bits?

Question

Pour le développement C++ pour des systèmes 32 bits (que ce soit Linux, Mac OS ou Windows, PowerPC ou x86) j'ai initialisé des pointeurs qui seraient sinon indéfinis (par exemple, ils ne peuvent pas immédiatement avoir une valeur propre) de cette manière :

int *pInt = reinterpret_cast(0xDEADBEEF);

(Pour éviter de taper et de rester DRY, le côté droit serait normalement dans une constante, par exemple BAD_PTR.)

Si pInt est déréférencé avant d'avoir une valeur propre, alors il crashera immédiatement sur la plupart des systèmes (au lieu de planter bien plus tard lorsque certaines mémoires sont écrasées ou que l'on entre dans une boucle infinie).

Évidemment, le comportement dépend du matériel sous-jacent (récupérer un entier de 4 octets à partir de l'adresse impaire 0xDEADBEEF d'un processus utilisateur peut être parfaitement valide), mais le crash a été à 100% fiable pour tous les systèmes pour lesquels j'ai développé jusqu'à présent (Mac OS 68xxx, Mac OS PowerPC, Linux Redhat Pentium, Windows GUI Pentium, Windows console Pentium). Par exemple, sur PowerPC, il est illégal (défaut d'accès) de récupérer un entier de 4 octets à partir d'une adresse impaire.

Quelle est une bonne valeur pour cela sur les systèmes 64 bits ?

Answer 1

0xBADC0FFEE0DDF00D

Answer 2

Selon Wikipedia, BADC0FFEE0DDF00D est utilisé sur les systèmes IBM RS/6000 64 bits pour indiquer des registres CPU non initialisés.

Answer 3

La plupart des systèmes actuels 64 bits vous permettent d'utiliser uniquement les 248 – 252 bits les plus faibles de l'espace d'adressage; les bits plus élevés de l'adresse doivent être tous à zéro. Certains processeurs (par exemple amd64) vous permettent également d'utiliser les 248 – 252 bits les plus élevés. Les adresses en dehors de ces plages ne peuvent jamais être mappées vers une mémoire accessible ; le matériel ne le permet tout simplement pas.

Je vous recommande donc d'utiliser une valeur proche de 263, qui n'est nulle part près des espaces potentiellement utilisables. Si les quatre premiers chiffres hexadécimaux sont 7ff8, la valeur sera un NaN en double précision à virgule flottante, ce qui est pratique. Alors ma phrase hexadécimale mignonne suggérée est 0x7FF8BADFBADFBADF.

En passant, vous ne souhaitez vraiment pas utiliser une valeur proche de 0, car cela rend difficile de distinguer un déréférencement de décalage de NULL — un accès à un membre de structure, par exemple — d'un déréférencement du motif poison.

Answer 4

En général, peu importe exactement quel motif vous écrivez, ce qui importe est que vous puissiez identifier le motif afin de déterminer où les problèmes se produisent. Il se trouve juste que dans le noyau Linux, ils sont souvent choisis de telle sorte qu'ils peuvent être piégés si les adresses sont déréférencées.

Jetez un œil dans le noyau Linux à include/linux/poison.h. Ce fichier contient différentes valeurs empoisonnées pour de nombreux sous-systèmes du noyau. Il n'y a pas de valeur empoisonnée appropriée.

De plus, vous pouvez consulter les fichiers d'inclusion par architecture dans l'arborescence source du noyau Linux pour des informations sur ce qui est utilisé sur des architectures spécifiques.

Answer 5

Je suppose que vous avez déjà exclu NULL (c'est-à-dire 0 sans le transtypage). C'est certainement le choix le plus sûr, car, en théorie, un pointeur valide pourrait pointer vers l'adresse mémoire 0xDEADBEEF (ou toute autre adresse mémoire non-NULL).