2010-09-09 21 views
3

Donc, je me demande s'il y a un bon marqueur à choisir en C, en dehors de la commune 0xDEADBEEF ou moins attrayant (pour le code approprié) 0x0BADA550.Que choisir comme un bon marqueur en C?

Quel est votre favori? Y a-t-il une raison de choisir une valeur particulière?

+0

duplication possible de [valeur mémorisable de 32 bits en tant que constante] (http://stackoverflow.com/questions/1810529/memorable-32-bit-value-as-a-constant) –

+0

Pour moi, ce n'était pas Pour fermer, comme indiqué dans diverses réponses de telles valeurs sont choisies non seulement pour l'esthétique et la reconnaissabilité, mais aussi pour une sorte de fonctionnalité (voir les choses int 3). –

Répondre

6

Wikipédia a un whole page sur ce sujet; il fournit beaucoup d'exemples et de logiciels célèbres dans lesquels ils sont utilisés.

Quoi qu'il en soit, si vous travaillez sur x86, vous devriez envisager de suivre la suggestion de @ torak, la mémoire remplie de int 3 m'a sauvé plusieurs fois. Si vous vous sentez créatif, vous pouvez le rendre plus reconnaissable et utiliser CC90CC90, ce qui se traduit par alternance int 3 et nop.

0

0xBABECAFE, 0xBADADD00, 0xBADBAD00, 0xFADEFADE

0xCAFEBABE est, je comprends, le nombre magique pour Java. La seule chose qui améliore un autre est l'improbabilité d'apparaître dans les données ou dans la mémoire non initialisée. N'utilisez donc pas 0x00000000 ou tous les F s.

0

Cela dépend de ce que vous essayez de marquer. Par exemple, avez-vous besoin de faire la distinction entre la mémoire allouée mais non initialisée et la mémoire désallouée? Si oui, vous avez besoin de différents marqueurs pour les deux.

4

Le seul marqueur que je peux penser de qui pourrait avoir plus que la valeur asthénique est 0xCCCCCCCC. Si, par une sorte d'erreur, il a été exécuté 0xCC se traduit par une instruction INT 3.

Ceci fonctionnera dans IA-32 et x86-64. Je ne suis pas sûr s'il y a des équivalents pour d'autres architectures.

+2

... sur les machines x86 (?) ... – dmckee

+0

@dmckee: Ahh oui. Je vais ajouter cela. Merci! – torak

+1

Je pense que 0xCCCCCCCC a un avantage supplémentaire en ce sens qu'il pointe généralement vers l'espace mémoire virtuel du noyau, en essayant d'utiliser un tel pointeur de l'espace utilisateur, il planterait l'application (ce qui est idéal pour le débogage). –

3

Eh bien j'ai toujours choisi 0x80000000, 0x80000001 incrémentation pour chaque nouveau type de région pour chatouiller des valeurs inattendues avec des entiers signés. L'utilisation de ces valeurs sera étrangement grande pour les types non signés, en grande partie négative pour les types signés, et deviendra brusquement positive pour toutes les soustractions faites (testant ainsi d'autres bogues en même temps). Ceci a un autre effet secondaire intéressant, en ce que divers bits ALU seront définis tels que le débordement, qui peut être détecté en utilisant -ftrapv et d'autres indicateurs du compilateur.

0

Tout le monde a sa préférence. Si tout le monde dans l'équipe utilise un marqueur différent, cela peut aider à déterminer la source d'une erreur. Comme dans:

"DEADBEEF? Oh, cela doit être du code de John."