Le problème semblerait plutôt être que beaucoup de programmes écrits en C pourraient avantageusement être écrits dans un autre langage de programmation, qui ne soit pas un langage de bas niveau.
Ou alors, on pourrait considérer que le C pourrait fournir un minimum de support pour les chaînes de caractères dans le modèle length+data. Sauf que l'on s'expose alors à un autre problème, qui n'est pas si simple qu'il n'y paraît: dans l'article, l'auteur indique
Using an address + length format would cost one more byte of overhead than an address + magic_marker format
Traduction grossière: «Utiliser un format adresse + taille ne coûterait qu'un octet de plus par rapport au format adresse + valeur_magique».
C'était vrai à une époque donnée, sur un CPU donné, mais dans la pratique, les CPUs n'utilisent pas la même taille de mots, du coup, cette assertion est fausse dans pas mal de cas aujourd'hui. Accessoirement, ça limiterait la taille des chaînes de caractère à 65535 octets. Difficile, avec des fichiers de log ou des données XML un peu volumineux (avec UTF8, ça passera encore, mais en unicode 32, on a moins de 17000 caractères)...
Du coup, même si c'est vrai que ça pose des problèmes de sécurité quand on ne fais pas gaffe, et que c'est facile de ne pas faire gaffe, je pense que c'est un sacré raccourcis que de dire que c'est l'erreur la plus coûteuse.
Le C n'est pas juste fait pour tourner sur du matériel grand public, mais pour écrire du code portable (et pas forcément porté), efficace et puissant. Avec ces contraintes, le choix «null-terminated» était plus logique que celui d'utiliser des tailles: la taille des mots change avec les processeurs et le temps, les besoins aussi.
Du coup, le choix avec le moins d'impact sur les conceptions futures est bien le marqueur de fin: ce mécanisme marche juste sur la totalité des architectures sans la moindre modification de code, est indépendant du compilateur (quelle est la taille standard de size_t? Sur n'importe quel compilo ou CPU?).
Si l'on à besoin de manipuler beaucoup de chaînes de caractère, on prend un outil fait pour, quitte à introduire une dépendance (qui aurait éventuellement pu être incluse dans le standard, depuis, mais passons).
[^] # Re: Liens
Posté par freem . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 8.
Ou alors, on pourrait considérer que le C pourrait fournir un minimum de support pour les chaînes de caractères dans le modèle length+data. Sauf que l'on s'expose alors à un autre problème, qui n'est pas si simple qu'il n'y paraît: dans l'article, l'auteur indique
Traduction grossière: «Utiliser un format adresse + taille ne coûterait qu'un octet de plus par rapport au format adresse + valeur_magique».
C'était vrai à une époque donnée, sur un CPU donné, mais dans la pratique, les CPUs n'utilisent pas la même taille de mots, du coup, cette assertion est fausse dans pas mal de cas aujourd'hui. Accessoirement, ça limiterait la taille des chaînes de caractère à 65535 octets. Difficile, avec des fichiers de log ou des données XML un peu volumineux (avec UTF8, ça passera encore, mais en unicode 32, on a moins de 17000 caractères)...
Du coup, même si c'est vrai que ça pose des problèmes de sécurité quand on ne fais pas gaffe, et que c'est facile de ne pas faire gaffe, je pense que c'est un sacré raccourcis que de dire que c'est l'erreur la plus coûteuse.
Le C n'est pas juste fait pour tourner sur du matériel grand public, mais pour écrire du code portable (et pas forcément porté), efficace et puissant. Avec ces contraintes, le choix «null-terminated» était plus logique que celui d'utiliser des tailles: la taille des mots change avec les processeurs et le temps, les besoins aussi.
Du coup, le choix avec le moins d'impact sur les conceptions futures est bien le marqueur de fin: ce mécanisme marche juste sur la totalité des architectures sans la moindre modification de code, est indépendant du compilateur (quelle est la taille standard de size_t? Sur n'importe quel compilo ou CPU?).
Si l'on à besoin de manipuler beaucoup de chaînes de caractère, on prend un outil fait pour, quitte à introduire une dépendance (qui aurait éventuellement pu être incluse dans le standard, depuis, mais passons).