Le "comportement indéfini" permet-il vraiment à n'importe quoi de se produire ?

Question

L'exemple apocryphe classique de "comportement non défini" est, bien sûr, celui des "démons nasaux" - une impossibilité physique, indépendamment de ce que les normes C et C++ autorisent.

Parce que les communautés C et C++ ont tendance à mettre l'accent sur l'imprévisibilité du comportement non défini et sur l'idée que le compilateur est autorisé à faire faire au programme des choses littérales tout ce qui est lorsque l'on rencontre un comportement non défini, j'avais supposé que la norme n'imposait aucune restriction sur le comportement de, eh bien, le comportement non défini.

Mais le La citation pertinente de la norme C++ semble être la suivante :

[C++14: defns.undefined]: [..] Le comportement non défini autorisé va de l'ignorance totale de la situation avec des résultats imprévisibles, au comportement pendant la traduction ou l'exécution du programme d'une manière documentée et caractéristique de l'environnement (avec ou sans émission d'un message de diagnostic), en passant par l'interruption de la traduction ou de l'exécution (avec émission d'un message de diagnostic). [..]

Il s'agit en fait d'un petit ensemble d'options possibles :

• Ignorer la situation -- Oui, la norme poursuit en disant que cela aura des "résultats imprévisibles", mais ce n'est pas la même chose que le compilateur en insérant (ce qui, je suppose, serait un prérequis pour, vous savez, les démons nasaux).
• Se comporter d'une manière documentée et caractéristique de l'environnement -- cela semble en fait relativement bénin. (Je n'ai certainement pas entendu parler de cas documentés de démons nasaux).
• Interrompre la traduction ou l'exécution -- avec un diagnostic, pas moins. Si seulement toutes les UB se comportaient aussi bien.

Je suppose que dans la plupart des cas, les compilateurs choisissent d'ignorer le comportement non défini ; par exemple, lors de la lecture d'une mémoire non initialisée, il serait vraisemblablement anti-optimisation d'insérer un quelconque code pour assurer un comportement cohérent. Je suppose que les types plus étranges de comportement non défini (tels que " voyage dans le temps ") relèverait de la deuxième catégorie - mais cela exige que ces comportements soient documentés et " caractéristiques de l'environnement " (donc je suppose que les démons nasaux ne sont produits que par des ordinateurs infernaux ?).

Ai-je mal compris la définition ? S'agit-il de simples exemples de ce qui pourrait constituer un comportement non défini, plutôt qu'une liste complète d'options ? L'affirmation selon laquelle "tout peut arriver" est-elle simplement considérée comme un effet secondaire inattendu de l'ignorance de la situation ?

Deux petits points de clarification :

• Je pensais que la question initiale était claire, et je pense que c'est le cas pour la plupart des gens, mais je vais quand même l'expliquer : Je réalise que "démons nasaux" est une plaisanterie.
• Veuillez ne pas écrire une (autre) réponse expliquant que UB permet des optimisations de compilateur spécifiques à la plate-forme, à moins que vous ne également expliquer comment il permet des optimisations qui définie par la mise en œuvre comportement ne serait pas permettre.

---

Cette question n'était pas destinée à servir de forum de discussion sur les (dé)mérites d'un comportement indéfini, mais c'est un peu ce qu'elle est devenue. Dans tous les cas, ce fil de discussion à propos d'un hypothétique compilateur C sans comportement indéfini peut présenter un intérêt supplémentaire pour ceux qui pensent que ce sujet est important.

Answer 1

Oui, il permet tout ce qui peut arriver. La note ne fait que donner des exemples. La définition est assez claire :

Comportement non défini : comportement pour lequel la présente Norme internationale n'impose aucune exigence.

---

Point de confusion fréquent :

Vous devez comprendre que "aucune exigence" également signifie que la mise en œuvre est NO nécessaire pour laisser le comportement indéfini ou faire quelque chose de bizarre/non déterministe !

L'implémentation est parfaitement autorisée par la norme C++ à documenter un comportement sain et à se comporter en conséquence. 1 Donc, si votre compilateur prétend faire un enveloppement en cas de dépassement de capacité signé, la logique (la raison ?) voudrait que vous vous reposiez sur ce comportement. sur ce compilateur . N'attendez pas d'un autre compilateur qu'il se comporte de la même manière s'il ne le prétend pas.

_{¹Il est même permis de documenter une chose et d'en faire une autre. Ce serait stupide, et cela vous ferait probablement jeter le compilateur à la poubelle - pourquoi faire confiance à un compilateur dont la documentation vous ment - mais ce n'est pas contre le standard C++.}

Answer 2

L'un des objectifs historiques du comportement indéfini était de permettre la possibilité que certaines actions puissent avoir des effets différents sur l'environnement. potentiellement utile effets sur les différentes plateformes. Par exemple, dans les premiers jours du C, étant donné

int i=INT_MAX;
i++;
printf("%d",i);

certains compilateurs pouvaient garantir que le code imprimerait une valeur particulière (pour une machine à deux compléments, ce serait typiquement INT_MIN), tandis que d'autres garantissaient que le programme se terminerait sans atteindre le printf. Selon les exigences de l'application, l'un ou l'autre comportement peut être utile. Laisser le comportement indéfini signifiait qu'une application où une terminaison anormale du programme était une conséquence acceptable d'un débordement, mais où la production d'une sortie apparemment valide mais fausse ne l'était pas, pouvait renoncer à la vérification du débordement si elle était exécutée sur une plate-forme qui le piégerait de manière fiable, et une application où une terminaison anormale en cas de débordement n'était pas acceptable, mais où la production d'une sortie arithmétiquement incorrecte l'était, pouvait renoncer à la vérification du débordement si elle était exécutée sur une plate-forme où les débordements n'étaient pas piégés.

Récemment, cependant, certains auteurs de compilateurs semblent s'être lancés dans un concours pour voir qui peut éliminer le plus efficacement tout code dont l'existence ne serait pas imposée par la norme. Étant donné, par exemple...

#include <stdio.h>

int main(void)
{
  int ch = getchar();
  if (ch < 74)
    printf("Hey there!");
  else
    printf("%d",ch*ch*ch*ch*ch);
}

un compilateur hyper-moderne peut conclure que si ch est égal ou supérieur à 74, le calcul de ch*ch*ch*ch*ch produirait un comportement indéfini, et en tant que le programme devrait imprimer "Hey there !" inconditionnellement quel que soit le quel que soit le caractère tapé.

Answer 3

Nitpicking : Vous n'avez pas cité de norme.

Ce sont les sources utilisées pour générer les versions préliminaires de la norme C++. Ces sources ne doivent pas être considérées comme une publication de l'ISO, ni les documents générés à partir d'elles, à moins qu'elles ne soient officiellement adoptées par le groupe de travail C++ (ISO/CEI JTC1/SC22/WG21).

Interprétation : Les notes ne sont pas normatif conformément aux directives ISO/CEI, partie 2.

Les notes et les exemples intégrés dans le texte d'un document ne doivent être utilisés que pour donner des informations complémentaires destinées à faciliter la compréhension ou l'utilisation du document. Ils ne doivent pas contenir d'exigences ("doit" ; voir 3.3.1 et tableau H.1) ou toute information considérée comme indispensable à l'utilisation du document par exemple, des instructions (impératif ; voir tableau H.1), des recommandations ("devrait" ; voir 3.3.2 et tableau H.2) ou une permission ("peut" ; voir tableau H.3). Les notes peuvent être rédigées comme une déclaration de fait.

C'est moi qui souligne. Ce seul fait exclut la "liste complète des options". En revanche, le fait de donner des exemples est considéré comme une "information complémentaire destinée à faciliter la compréhension [ ] du document".

Gardez à l'esprit que le mème du "démon nasal" n'est pas à prendre au pied de la lettre, tout comme l'utilisation d'un ballon pour expliquer le fonctionnement de l'expansion de l'univers n'a rien à voir avec la réalité physique. C'est pour illustrer le fait qu'il est imprudent de discuter de ce que le "comportement indéfini" devrait faire quand il est permis de faire n'importe quoi. Oui, cela signifie qu'il n'y a pas de véritable élastique dans l'espace.

Answer 4

La définition d'un comportement non défini, dans chaque norme C et C++, est essentiellement que la norme n'impose aucune exigence sur ce qui se passe.

Oui, cela signifie que toute issue est permise. Mais il n'y a pas de résultats particuliers qui sont requis de se produire, ni de résultats qui sont requis de ne pas se produire. Peu importe que vous disposiez d'un compilateur et d'une bibliothèque qui produisent systématiquement un comportement particulier en réponse à un cas particulier de comportement non défini - un tel comportement n'est pas requis et peut changer même dans une future version de correction de bogues de votre compilateur - et le compilateur sera toujours parfaitement correct selon chaque version des normes C et C++.

Si votre système hôte dispose d'un support matériel sous la forme d'une connexion à des sondes qui sont insérées dans vos narines, il est tout à fait possible qu'une occurrence de comportement non défini provoque des effets nasaux indésirables.

Answer 5

Je pensais ne pas répondre à une de vos points, puisque les autres réponses de répondre à la question générale assez bien, mais ils ont laissé ce n'est fait.

"En ignorant la situation -- Oui, le standard va jusqu'à dire que cela va avoir des "conséquences imprévisibles", mais ce n'est pas le même que le compilateur de l'insertion de code (ce qui je suppose sera une condition préalable, vous le savez, les démons)."

Une situation dans laquelle nasale démons peut très raisonnablement s'attendre à se produire avec un bon compilateur, sans le compilateur d'insérer n'IMPORTE quel code, serait la suivante:

if(!spawn_of_satan)
    printf("Random debug value: %i\n", *x); // oops, null pointer deference
    nasal_angels();
else
    nasal_demons();

Un compilateur, si elle peut prouver que *x est un déréférencement de pointeur null, a parfaitement le droit, dans le cadre de l'optimisation, de la à dire "OK, donc, je vois qu'ils ont déréférencé un pointeur null dans cette branche de la si. Par conséquent, dans le cadre de cette branche, je suis autorisé à faire quoi que ce soit. Donc, je peux donc d'optimiser:"

if(!spawn_of_satan)
    nasal_demons();
else
    nasal_demons();

"Et à partir de là, je peux optimiser:"

nasal_demons();

Vous pouvez voir comment ce genre de chose peut dans certaines circonstances s'avérer très utile pour une optimisation du compilateur, et encore provoquer des catastrophes. Je ne vois quelques exemples tout à l'arrière de cas où, en fait, il EST important pour l'optimisation d'être en mesure d'optimiser ce genre de cas. Je pourrais essayer de creuser plus tard quand j'aurai plus de temps.

EDIT: Un exemple qui vient du plus profond de mon mémoire d'un cas où il est utile pour l'optimisation de l'endroit où vous très fréquemment un pointeur NUL (peut-être en inline fonctions d'assistance), même après avoir déjà déréférencé et sans avoir changé. L'optimisation du compilateur peut voir que vous avez déréférencé et ainsi d'optimiser tous les "est NULL" vérifications, car si vous avez déréférencé et il EST nul, tout est permis, y compris tout simplement pas l'exécution de l' "est NULL" contrôles. Je crois que les mêmes arguments s'appliquent à d'autres comportements indéfinis.