Contexte historique

Le langage C, créé en 1972, a connu trois révisions normatives majeures avant 2016 : C89 (ISO/IEC 9899:1990), C99 (ISO/IEC 9899:1999) et C11 (ISO/IEC 9899:2011). Chaque norme a introduit des fonctionnalités nouvelles – par exemple les long long int en C99 ou les _Atomic en C11 – tout en conservant la compatibilité ascendante. En parallèle, des standards de facto, notamment les extensions GNU (glibc, GCC) et les spécifications POSIX, ont façonné la pratique quotidienne des développeurs, surtout dans les environnements Unix‑like.

Principaux standards de facto

Les extensions GNU offrent des constructions inexistantes dans les normes ISO, comme __attribute__((aligned(16))) ou les blocs de code ({ ... }) qui permettent d’évaluer des expressions complexes. En 2016, GCC version 6 était largement déployée, supportant à la fois les extensions GNU et les fonctionnalités C11, ce qui créait un chevauchement entre les deux mondes. POSIX.1‑2008 (aussi appelé POSIX 2008) définit des API de système d’exploitation – pthread_create, mmap, etc. – qui sont implémentées de façon quasi universelle sur Linux, macOS et les BSD. Ces API ne sont pas couvertes par la norme C, mais elles sont indispensables pour le développement système.

Un autre standard de facto, le Microsoft Visual C++ (MSVC), propose des variantes de la bibliothèque standard (_aligned_malloc, __declspec(thread)) et un modèle de compilation distinct. En 2016, MSVC 14.0 supportait partiellement C11, mais restait limité aux extensions Microsoft, créant ainsi une fragmentation supplémentaire entre les plateformes.

Implications pour le développement

Le recours aux extensions GNU améliore la performance grâce à des contrôles précis de l’alignement mémoire : 

#include 
int main(){
    int x __attribute__((aligned(32))) = 0;
    return x;
}
Ce code garantit un alignement de 32 octets, exploitable par les instructions SIMD. Cependant, le même code échoue à la compilation sous MSVC, où l’attribut __declspec(align(32)) est requis. Cette incompatibilité impose aux équipes de maintenir des chemins de code conditionnels, augmentant la charge de test et le risque d’erreurs.

Les fonctionnalités C11, comme _Static_assert et les types atomiques, offrent des garanties de sécurité à la compilation et à l’exécution. Par exemple : 

#include 
_Static_assert(sizeof(void*) == 8, "64‑bit required");
Cette assertion compile‑time détecte immédiatement une cible non‑64 bits, évitant des comportements indéfinis. Néanmoins, l’adoption de C11 reste partielle : les bibliothèques tierces (OpenSSL, libcurl) n’ont pas uniformément migré, et les toolchains embarqués restent bloqués sur C99 ou même C89.

En pratique, les développeurs doivent choisir entre conformité stricte à la norme ISO (portabilité maximale) et exploitation des extensions de facto (performance ou fonctionnalité accrue). La décision dépend du cycle de vie du produit, du public cible et du niveau de contrôle de la chaîne d’outils. Sans une harmonisation officielle entre les standards ISO et les extensions dominantes, le paysage du C demeure fragmenté, obligeant les équipes à gérer explicitement les divergences à chaque version de compilateur.