@Renault: Je n’aime pas ton argument de la compatibilité ascendante. C’est faux, C strict où non, la compatibilité n’est que moyenne. Grossomodo, ça marche mais, c’est bien plus compliqué que ça.
Je n’ai pas dit que cette compatibilité était parfaite, mais elle est là et globalement ils sont frileux (à raison) à chambouler la syntaxe et les règles de base.
Et c’est normal, le C et C++ sont partout dans la base d’un système. Dans mon métier je le constate fréquemment quand GCC durci un peu certaines règles par défaut (ce qu’elle a fait depuis 10 ans régulièrement), le travail que cela induit derrière est énorme.
C’est vaguement présent, mais il suffit d’une nouvelle optimisation pour faire péter un code buggué qui tombait en marche. Ce ne sont pas des "règles de bases", ce sont des comportements aux limites que nous avions observés et que nous avons supposés, à tord, comme étant pérennes.
Il ne faut en aucun cas supposer que le code produit sur un comportement non défini sera toujours identique avec les versions futures d’un même compilateur.
Maintenant on commence à avoir des warnings qui s’améliorent de version en version, des sanitiseurs, des compilos alternatifs pour compiler les tests, des outils d’analyse de code. Il faut profiter de tout cela pour réduire les risques d’UB dans nos codes, et d’avoir des produits qui tombent en marche.
