Quels sont les comportements non définis/non spécifiés les plus courants en C que vous rencontrez ?

Question

Un exemple de comportement non spécifié dans le langage C est l'ordre d'évaluation des arguments d'une fonction. Il peut être de gauche à droite ou de droite à gauche, vous ne le savez pas. Cela affecte la façon dont foo(c++, c) ou foo(++c, c) est évaluée.

Quel autre comportement non spécifié peut surprendre le programmeur non averti ?

Answer 1

Question d'un juriste linguiste. D'accord.

Mon top 3 personnel :

1. violation de la règle stricte de l'aliasing

2. violation de la règle stricte de l'aliasing

3. violation de la règle stricte de l'aliasing

   -)

Editer Voici un petit exemple qui se trompe deux fois :

(en supposant qu'il s'agit d'ints 32 bits et de little endian)

float funky_float_abs (float a)
{
  unsigned int temp = *(unsigned int *)&a;
  temp &= 0x7fffffff;
  return *(float *)&temp;
}

Ce code tente d'obtenir la valeur absolue d'un flottant en jouant sur le bit de signe directement dans la représentation d'un flottant.

Cependant, le résultat de la création d'un pointeur sur un objet en passant d'un type à un autre n'est pas valide en C. Le compilateur peut supposer que des pointeurs de types différents ne pointent pas vers le même morceau de mémoire. Ceci est vrai pour tous les types de pointeurs sauf void* et char* (le signe n'a pas d'importance).

Dans le cas ci-dessus, je le fais deux fois. Une fois pour obtenir un int-alias pour le float a, et une fois pour reconvertir la valeur en float.

Il existe trois façons valables de procéder.

Utiliser un pointeur char ou void lors de la conversion. Ces pointeurs sont toujours des alias de n'importe quoi, ils sont donc sûrs.

float funky_float_abs (float a)
{
  float temp_float = a;
  // valid, because it's a char pointer. These are special.
  unsigned char * temp = (unsigned char *)&temp_float;
  temp[3] &= 0x7f;
  return temp_float;
}

Utiliser memcopy. Memcpy prend des pointeurs de type void, ce qui force également l'aliasing.

float funky_float_abs (float a)
{
  int i;
  float result;
  memcpy (&i, &a, sizeof (int));
  i &= 0x7fffffff;
  memcpy (&result, &i, sizeof (int));
  return result;
}

Troisième solution valable : utiliser les unions. Il s'agit explicitement d'une pas indéfini depuis C99 :

float funky_float_abs (float a)
{
  union 
  {
     unsigned int i;
     float f;
  } cast_helper;

  cast_helper.f = a;
  cast_helper.i &= 0x7fffffff;
  return cast_helper.f;
}

Answer 2

Mon comportement indéfini préféré est que si un fichier source non vide ne se termine pas par une nouvelle ligne, le comportement est indéfini.

Je pense qu'il est vrai qu'aucun compilateur que j'ai jamais vu n'a traité un fichier source différemment selon qu'il était ou non terminé par une nouvelle ligne, si ce n'est pour émettre un avertissement. Ce n'est donc pas vraiment quelque chose qui surprendra les programmeurs non sensibilisés, si ce n'est qu'ils pourraient être surpris par l'avertissement.

Ainsi, pour les véritables problèmes de portabilité (qui dépendent le plus souvent de l'implémentation plutôt que d'être non spécifiés ou non définis, mais je pense que cela s'inscrit dans l'esprit de la question) :

• char n'est pas nécessairement (non) signé.
• int peut être de n'importe quelle taille à partir de 16 bits.
• ne sont pas nécessairement formatés ou conformes à l'IEEE.
• les types de nombres entiers ne sont pas nécessairement des compléments à deux, et le dépassement de capacité arithmétique des nombres entiers entraîne un comportement non défini (le matériel moderne ne se bloque pas, mais certaines optimisations du compilateur entraînent un comportement différent de l'enveloppement, même si c'est ce que fait le matériel). Par exemple if (x+1 < x) peut être optimisé comme étant toujours faux lorsque x a un type signé : voir -fstrict-overflow dans GCC).
• "/", "." et " " dans un #include n'ont pas de signification définie et peuvent être traités différemment par différents compilateurs (cela varie effectivement, et si cela se passe mal, cela vous gâchera la journée).

Des problèmes très sérieux qui peuvent être surprenants même sur la plateforme sur laquelle vous avez développé, parce que le comportement n'est que partiellement non défini / non spécifié :

• Le threading POSIX et le modèle de mémoire ANSI. L'accès simultané à la mémoire n'est pas aussi bien défini que les novices le pensent. volatile ne fait pas ce que les novices pensent. L'ordre des accès à la mémoire n'est pas aussi bien défini que les novices le pensent. Accès peut peuvent être déplacés à travers les barrières de mémoire dans certaines directions. La cohérence de la mémoire cache n'est pas nécessaire.

• Profiler un code n'est pas aussi simple qu'on le pense. Si votre boucle de test n'a aucun effet, le compilateur peut la supprimer en tout ou en partie. inline n'a pas d'effet défini.

Et, comme l'a mentionné Nils en passant, je crois :

• VIOLANT LA RÈGLE STRICTE DE L'ALIASING.

Answer 3

Diviser quelque chose par un pointeur vers quelque chose. Cela ne compile pas pour une raison ou une autre... :-)

result = x/*y;

Answer 4

Ma préférée est celle-ci :

// what does this do?
x = x++;

Pour répondre à certains commentaires, il s'agit d'un comportement non défini selon la norme. En voyant cela, le compilateur est autorisé à faire n'importe quoi, jusqu'à formater votre disque dur. Voir par exemple ce commentaire ici . Il ne s'agit pas de savoir si l'on peut raisonnablement s'attendre à un certain comportement. En raison de la norme C++ et de la manière dont les points de séquence sont définis, cette ligne de code est en fait un comportement non défini.

Par exemple, si nous avions x = 1 avant la ligne ci-dessus, quel serait le résultat valide après ? Quelqu'un a fait remarquer qu'il devrait être

x est incrémenté de 1

de sorte que nous devrions voir x == 2 par la suite. Cependant, ce n'est pas vrai, vous trouverez des compilateurs qui ont x == 1 après, ou peut-être même x == 3. Il faudrait regarder de près l'assemblage généré pour voir pourquoi, mais les différences sont dues au problème sous-jacent. Essentiellement, je pense que c'est parce que le compilateur est autorisé à évaluer les deux instructions d'affectation dans l'ordre qu'il souhaite, de sorte qu'il pourrait faire l'opération suivante x++ d'abord, ou le x = d'abord.

Answer 5

Un compilateur n'a pas à vous dire que vous appelez une fonction avec un mauvais nombre de paramètres ou un mauvais type de paramètres si le prototype de la fonction n'est pas disponible.