Fedora et GCC 6 montrent de mauvaises pratiques de codage

Pour leur version 24, les développeurs de la distribution Linux Fedora ont notamment voulu utiliser la dernière version du compilateur GCC, qui sera la GCC 6.1 quand la nouvelle version de la distribution sera disponible (GCC 6 est prévu pour avril 2016, Fedora 24 vers juin). Ainsi, cette semaine, les développeurs ont lancé une compilation complète de l’entièreté des paquets de Fedora, en préparation de ce changement de compilateur.

Leur processus était le suivant : d’abord tenter une compilation de tous les 17 741 paquets avec GCC 6, puis, pour ceux dont la compilation a échoué, retenter la compilation avec GCC 5. Si la compilation échoue deux fois, le problème vient du paquet, sinon de GCC. Un peu moins de mille paquets ont ainsi échoué deux fois, ce qui en laisse à peu près six cents qui ont échoué avec GCC 6 mais pas GCC 5. En comparaison, pour le passage de GCC 4.9 à GCC 5, moins de la moitié avait posé problème. La nouvelle version de GCC serait-elle si mauvaise ?

Effectivement, une série de ces problèmes était due à des régressions au niveau de GCC, des défauts qui ont rapidement été corrigés en vue de la sortie de la version finale. La majorité des cas, cependant, vient des développeurs des applications concernées. Pour une série d’entre eux, le problème vient du fait que GCC 6 compilera le code C++ par défaut en mode C++14 (au lieu de C++98, une norme bien dépassée) : ces paquets n’étaient pas prêts et ont dû être recompilés avec GCC 5.

Pour d’autres, certains changements dans l’implémentation de la bibliothèque standard C++ et, surtout, de nouveaux messages d’erreur ont montré des pratiques de programmation douteuses dans le chef des développeurs des applications disponibles dans Fedora. Les réponses des développeurs de GCC sont parfois éloquentes quant à ces mauvaises pratiques :

Citation:

---

The code is nonsense, what’s it even supposed to do? […] It’s useless, and only compiled by accident.
Allowing it with -fpermissive might make sense though, as that flag allows all kinds of terrible rubbish to compile.

---

Les mêmes défauts seront probablement remarqués par les autres distributions en passant à GCC 6, comme Gentoo, habituellement prompte à se mettre à jour.

Source : Fedora mass rebuild 2016.
Ce contenu a été publié dans C++ par dourouc05.

Tant mieux si ça peut inciter les développeurs à mettre à jour et à assainir leur code. Mais en même temps, ce n'est pas très surprenant qu'un compilateur C++14 qui n'est pas encore sorti n'arrive pas à compiler certains codes C++98...

Citation:

---

Envoyé par dourouc05

certains changements [...] ont montré des pratiques de programmation douteuses dans le chef des développeurs des applications disponibles dans Fedora.

---

Je ne comprends pas cette phrase : c'est quoi une pratique de programmation dans le chef des développeurs ?

Citation:

---

Envoyé par groharpon42

Je ne comprends pas cette phrase : c'est quoi une pratique de programmation dans le chef des développeurs ?

---

Un exemple est dans l'article : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550

Code:

---

1 2 3 4

typedef struct mytype { struct mytype *fieldptr0[0]; struct mytype *fieldptr[]; } mytype;

---

- Un VLA peut être présent dans une structure, à condition que ce soit le dernier membre de cette structure et qu'elle contienne au moins un champ autre que le VLA en question (ISO C99).
- Un array de taille 0 est une extension GNU C, extension assez pratique pour implémenter un protocole réseau de style [header:2] [size:2] [payload:n] : https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

Ici, on est donc dans un cas complètement bordeline où on a rajouté un champ inusité de taille 0 dans le seul but d'avoir un VLA seul dans une structure. Ca compilait, ça ne compile plus, les devs de gcc considèrent que c'était un bug et que ça a été corrigé, et les devs de Julia sont embêtés parce que cette structure est dans un header public (et fait donc partie de l'API).

Je suis plutôt d'accord avec l'équipe de GCC :D