Les standards du C (le langage, ISO/IEC 9899)

Ne fait pas parti d’un standard, mais est utile à mentionner : c-faq.com.

Voir aussi, sur des ajouts au standard, certains approuvés certains abandonnés : Experimental C standard libraries (cppreference.com).

Bien que le C soit un standard de fait, il n’en est pas universel pour autant. L’article ci‑dessous (qui me parle, pour des raisons que je ne décrit pas parce que pas assez de volonté pour ça à l’instant), décrit comment les processeurs actuels sont devenus complexes et gourmands en énergie, comme conséquence de vouloir continuer à donner l’illusion que le modèle sémantique du C est toujours valable alors qu’il ne l’est plus de puis longtemps. Dans le cas de l’exemple décrit dans l’article, la conséquence est même une lacune dans la fiabilité, une lacune malheureusement difficile à éviter.

Voir : C is not a low-level language — your computer is not a fast PDP‑11 (acm.org), David Chisnall, 2018.

Le mot clé “ restrict ” pour les “ pointer ”, pourrait être considéré comme capital, si on oubliait qu’il ne s’applique qu’au pointeur auquel il s’applique et non‑pas à ce que design le pointeur. En particulier, restrict ne permet pas d’affirmation sur l’aliasing indirect.

Il n’y a même pas besoin d’aller chercher une indirection lointaine, elle peut être tout prêt : si p1 et p2 désignent deux tableaux et que p2 pointe vers un élément de p1, on a bien un aliasing alors que p1 et p2 sont différents.

L’option “ -fsanitize=undefined ”, de Clang, le compilateur C de l’infrastructure LLVM, permet d’aider à déceler les opérations dont le résultat est indéfini d’après le standard du C. L’option produit une version instrumentée du programme, ce n’est pas une détection par de l’analyse statique.

En marge, même si ce n’est pas le sujet, ne pas oublier que le standard POSIX, lui aussi, contient des notes à propos de circonstances dans lesquelles le résultat de certaines opérations doit être considéré comme indéfini.