Code C : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | tp->tv_sec = attributes[0] / 10^9; tp->tv_nsec = attributes[0] % 10^9; range->pmin[TREND_FCT] = -10^10; range->pmax[TREND_MEAN] = 10^10; #define IRQ_CHINT5_LEVEL (12 ^ 7) #define IRQ_CHINT4_LEVEL (11 ^ 7) #define IRQ_CHINT3_LEVEL (10 ^ 7) #define IRQ_CHINT2_LEVEL (9 ^ 7) #define IRQ_CHINT1_LEVEL (8 ^ 7) |
Code C : | Sélectionner tout |
1 2 3 4 5 | read_bytes(&f, (char *) &(val), ( (n < (2 ^ 8)) ? 1 : ( (n < (2 ^ 16)) ? 2 : ( (n < (2 ^ 24)) ? 3 : 4 ) ) ) ); |
« GCC n’émet pas d’avertissement pour : short maxshort = 2^16;, int maxint = 2^32; long maxlong = 2^64; Il faut que ce soit le cas en C et en C++. Je ne vois pas de raison valable d'écrire 2^16 quand vous voulez dire 18 ou 10^9 quand vous voulez dire 3, donc c'est probablement un bogue », a lancé Jonathan Wakely sur la liste de diffusion de bugs de GCC. « Mon Dieu que de faussetés en une seule ligne de code », a réagi un internaute sur un tweet d’un des participants aux échanges sur la liste de diffusion dédiée à GCC. En fait, l’un des problèmes avec cette ligne de code est qu’étant donné que l’expression 2^32 est évaluée en considérant l’opérateur ^ comme un OU exclusif, il vient que la boucle n’aura pas le nombre d’itérations auquel le rédacteur du code s’attend.
Si des tiers ont beaucoup plus remonté les cas d’ambiguïté qui se posent avec ce qui s’apparente de prime abord à des exponentiations de base 2, il faut dire que le problème reste le même avec les autres bases. Cet état de choses complexifie la détermination de l’angle sous lequel l’avertissement à générer sous GCC doit être orienté.
« Je pense que les avertissements doivent porter sur les cas où les deux opérandes sont des nombres entiers. Seulement, peut-on traiter tous les entiers sur un pied d’égalité ? Est-ce que 0x11 ^ 0b0011 est faux ? En tout cas, ça ne l’est pas de façon aussi évidente que 2^8 et 2^32. Est-ce que ces erreurs n'arrivent qu'aux puissances de 2 et 10 ? Est-ce que ça vaut la peine d'avertir à propos de 3^4 ? Après d'autres recherches, je ne suis même pas sûr que 10^ soit assez commun pour m'inquiéter. Peut-être que le compilateur ne devrait générer un avertissement que pour les cas qui s’apparentent à une exponentiation de base 2. Amener GCC à générer un avertissement pour ces situations que l’on pourrait considéré comme une exponentiation dans laquelle la base et l’exposant sont égaux semble également faire sens. Cela pourrait permettre de mettre la main sur des cas comme 10^10, mais pas sur – 10^10 », a ajouté Jonathan Wakely.
Les discussions battent leur plein sur la liste de diffusion GCC. Quelque soit le consensus sur lequel elles vont déboucher, il ne faut pas perdre de vue qu’il s’agit seulement d’étendre les capacités du compilateur générer des avertissements pour des cas de figure précis. En général, les compilateurs sont dotés d’options d’activation ou de désactivation des avertissements, ce qui fait que l’utilisateur n’est pas dans l’obligation de subir un en particulier.
Source : liste de diffusion GCC
Et vous ?
Qu’en pensez-vous ?
Êtes-vous en accord avec la nécessité que GCC génère ce warning ? Si oui, quels sont d’après vous les axes les plus pertinents ?
En tombant sur une ligne de code C comme for (int i = 0 ; i < = ( 2^32) – 1 ; i++) {} avez-vous au premier regard le sentiment qu’il y a une erreur qui s’est glissée ?
Voir aussi :
La version 9.1 du compilateur GCC est disponible et prend en charge le C++17, plusieurs autres fonctionnalités sont ajoutées
GCC 9 sera la première version stable du compilateur à supporter le langage D, un nouveau front-end allonge la liste
GCC 8.1 est disponible, la nouvelle version majeure du compilateur libre vient avec un support expérimental de C++2a et d'autres fonctionnalités
GCC 8.2 est disponible. Cette mise à jour du compilateur libre corrige une centaine de bogues
GCC : la version 7.3 du compilateur libre est disponible avec des correctifs pour la vulnérabilité Spectre pour les dispositifs x86 et powerpc