Justification pour les comparaisons de pointeur en dehors d'un tableau pour être UB

Le 8086 est un processeur avec des registres 16 bits et un espace d'adressage 20 bits. Pour faire face au manque de bits dans ses registres, un ensemble de registres segment em> existe. Sur l'accès à la mémoire, l'adresse de la mémoire est calculée comme ceci:

address = 16 * segment + register

• Les objets peuvent avoir une taille d'au plus 64 kb li>
• Toutes les adresses d'un objet ont la même partie de segment li>
• comparer les adresses dans un objet peut être effectuée simplement en comparant la partie de registre; qui peut être fait dans une seule instruction li> ul>

  Cette comparaison rapide du cours ne fonctionne que lorsque les pointeurs sont dérivés de la même adresse de base, qui est l'une des raisons pour lesquelles la norme C définit les comparaisons du pointeur uniquement pour que les deux pointeurs indiquent dans le même objet. P>

  Si vous souhaitez une comparaison bien ordonnée pour tous les pointeurs, envisagez de convertir les pointeurs vers uintptr_t code> d'abord. p> p>

Historiquement, affirmant que cette action a invoqué un comportement indéfini signifiait que tout programme qui a utilisé de telles actions pourrait être attendu correctement uniquement sur ces mises en œuvre définies, pour cette action, le comportement répondant à leurs exigences EM>. Spécification d'une action invoquée un comportement indéfini ne voulait pas dire que les programmes utilisant de telles mesures devraient être considérés comme «illégitimes», mais devaient plutôt permettre à C d'être utilisé pour exécuter des programmes qui n'avaient pas besoin de telles actions, sur des plates-formes qui ne pouvaient pas efficacement Soutenez-les.

En règle générale, l'attente était qu'un compilateur émettrait soit la séquence d'instructions qui exécuteraient plus efficacement l'action indiquée dans les cas requis par la norme, et faire ce que cette séquence d'instructions se produisait dans d'autres cas. ou produirait une séquence d'instructions dont le comportement dans de tels cas a été jugé de manière plus "utile" que la séquence naturelle. Dans les cas où une action peut déclencher un piège au matériel, ou lorsque la déclenchement d'un piège à système d'exploitation pourrait être considérée comme précisée à l'exécution de la séquence d'instructions «naturelle» et lorsqu'un piège pourrait causer des comportements en dehors de la commande du compilateur C, La norme n'impose aucune exigence. Ces cas sont ainsi étiquetés comme "comportement non défini". P>

Comme d'autres l'ont noté, il existe certaines plates-formes où p1 , pour les pointeurs non liés P1 et P2, pourrait être garantie Rendement 0 ou 1, mais lorsque le moyen le plus efficace de comparer P1 et P2 qui fonctionnerait dans les cas définis par la norme pourrait ne pas défendre l'attente habituelle que p1 P2 || p1! = P2 code>. Si un programme écrit pour une telle plate-forme sait qu'elle ne comparera jamais délibérément des pointeurs non liés (impliquant que toute comparaison de ce type représenterait un bogue de programme), il peut être utile de disposer d'un essais de stress ou de dépannage des constructions générant des pièges à ces comparaisons. Le seul moyen de permettre à la norme d'autoriser de telles implémentations est de faire des comportements indéfinis tels que de tels comparaisons. P>

Jusqu'à récemment, le fait qu'une action particulière invoquerait le comportement non défini par la norme ne poserait généralement que des difficultés pour Les gens essayant d'écrire du code sur des plates-formes où l'action aurait des conséquences indésirables. En outre, sur des plates-formes où une action ne pouvait avoir des conséquences indésirables que si un compilateur est sorti de sa façon de le faire, il était généralement accepté de pratique pour les programmeurs de s'appuyer sur une telle action se comportant sensiblement. P>

si on accepte les notions qui: p>

1. Les auteurs de la norme attendaient que les comparaisons entre des pointeurs non liés fonctionneraient utilement sur ces plates-formes et que seules ces plates-formes, où les moyens les plus naturels de comparaison des pointeurs connexes fonctionneraient également avec des personnes non liées et p> li>

2. Il existe des plates-formes où la comparaison des pointeurs non liés serait problématique p> li> ol>

   Ensuite, il est tout à fait logique pour la norme de considérer les comparaisons de pointeur non liées comme un comportement non défini. Avaient-ils prévu que même des compilateurs pour les plates-formes qui définissent un classement mondial disjoint pour tous les pointeurs pourraient rendre les comparaisons de pointeur non liées nier les lois du temps et de la causalité (par exemple, donnée: p>

   int needle_in_haystack(char const *hs_base, int hs_size, char *needle)
   {
     for (int i=0; i<size; i++)
       if (hs_base+i == needle) return 1;
     return 0;
   }