Le nommage stdc_ est très brièvement justifié dans l'article. Historiquement, seules les quelques premières lettres (8, je crois) d'un nom de symbole étaient significatives. Ce n'était donc pas garanti de pouvoir avoir masuperfonction1 et masuperfonction2 (les deux pourraient voir leur symbole tronqué en "masuperf").
Les versions précédentes du C utilisaient donc des abbréviations de plus en plus obscures (memcpy, strcmp, wmbstocstr, ...) pour ne pas avoir de conflits dans ce cas.
La limite ayant été augmentée à 31 caractères, en utiliser 5pour le préfixe stdc_ devient raisonable.
Personellement je suis un peu embêté par le retrait des nombres octals. Je comprend la logique, mais ça ne va pas faciliter la migration de code existant qui en a besoin, ni de pouvoir écrire du code compatible avec plusieurs versions du standard.
[^] # Re: Oh
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien C'est parti pour la nouvelle version C2y du langage C. Évalué à 9.
Le nommage stdc_ est très brièvement justifié dans l'article. Historiquement, seules les quelques premières lettres (8, je crois) d'un nom de symbole étaient significatives. Ce n'était donc pas garanti de pouvoir avoir masuperfonction1 et masuperfonction2 (les deux pourraient voir leur symbole tronqué en "masuperf").
Les versions précédentes du C utilisaient donc des abbréviations de plus en plus obscures (memcpy, strcmp, wmbstocstr, ...) pour ne pas avoir de conflits dans ce cas.
La limite ayant été augmentée à 31 caractères, en utiliser 5pour le préfixe stdc_ devient raisonable.
Personellement je suis un peu embêté par le retrait des nombres octals. Je comprend la logique, mais ça ne va pas faciliter la migration de code existant qui en a besoin, ni de pouvoir écrire du code compatible avec plusieurs versions du standard.