Re: nullptr

Sauf qu'on parle de C. et ça c'est un problème de C++.
Le fait que C++ bug sur NULL, n'est pas une raison pour modifier le standard C il me semble.

En C NULL pose en theory problème soit avec les fonctions variadique, soit avec les _Generic (genre d'équivalent C de overloading de C++).

les _Generic, sont moins problématique, car:

• c'est du C11, donc pas si utiliser.
• il me semble que la seul utilité des _Generic dans la libc, c'est tgmath, qui gères des nombres, et donc n'ont pas gérés NULL.
• le code est évaluer à la compilation, et le compilo C, sait convertir 0 en pointeur sans UB.

par contre les fonctions variadic sont plus problématique car:

• très utiliser par la lib standard, et POSIX.
• la convention d'appel est implémentation define je croie, mais le standard dit que passer un int à une functions attendant une pointeur, c'est UB. (alors que avant C89, convertir des int à l'arrache en pointeur, c’était très courent, et considéré comme une feature de C (dalleur ça se voie dans certains code source de vieux projets comme libperl, qui dises que leur int value pourras toujours contenir un pointeur))

bien sur je parle de théory, car au final, la définition de NULL est implémentation define, et toutes les vrais libc l'ont définit comme ((void *)0), donc on esquive les problèmes évoqués plut haut.
Mais le fait que ça reste une source de bug théorique, et que en C++ c'est pas théorique, ont je suppose poussé à rajouter nullptr au standard.