La question si j'ai bien compris, est de patcher le C/C++ pour qu'il puisse gérer la mémoire de manière pluis sûre, parce que ce serait moins compliqué d'adapter le code existant à une nouvelle gestion mémoire que tout réécrire en rust … Ca se défend, mais je ne suis pas convaincu : ça dépendra surtout je pense de la façon dont le code a été écrit initialement. Pour du code écrit relativement récemment avec un respect de bonnes pratiques de dev, je pense que ça se tient. Pour du code plus ancien, je ne suis pas sûr que l'on y perde beaucoup à tout réécrire. Je pense que c'est du cas par cas.
Sinon je réagis à ceci :
With subsets it is too easy to create an unsafe hole where memory usage goes unchecked in what is supposedly memory safe code. Rust is not immune, is also vulnerable. Rust programs may open a hole using the Rust 'unsafe' keyword, and widely do so to access notoriously unsafe C pointers."
Je pense que même les plus fervents défenseurs de Rust n'ont jamais prétendu que Rust était invulnérable. Par contre le fait que du code potentielement vulnérable soit dans des blcs "unsafe" spécifiquements déclarés permet de bien localiser ce code. En ne limitant les blocs unsafe qu'au strict nécessaire, on évite des erreurs d'inattention dans tout le reste du code.
Je n'ai pas compris en détail les solutions memory save envisagées pour C++ (j'ai laché le C++ depuis (trop) longtemps). Si quelqu'un pouvait expliquer ici les principes je lui serais très reconnaissant.
La question si j'ai bien compris, est de patcher le C/C++ pour qu'il puisse gérer la mémoire de manière pluis sûre, parce que ce serait moins compliqué d'adapter le code existant à une nouvelle gestion mémoire que tout réécrire en rust … Ca se défend, mais je ne suis pas convaincu : ça dépendra surtout je pense de la façon dont le code a été écrit initialement.
Ben personnellement j’irai plutôt dans la direction d’adapter le code existant si possible. Par exemple le jeu Unvanquished c’est environ 20 000 lignes dans le moteur et près de 12 000 dans le jeu lui-même, sans compter certaines bibliothèques et autre outils que l’on maintient. Personne n’ira réécrire ça. D’ailleurs historiquement notre code a été porté de C vers le C++, et ça a été possible parce que tu peux commencer à compiler du C avec un compilateur C++ assez facilement avant de commencer à utiliser des choses qui n’existent que dans le C++. Un effort similaire pour porter progressivement vers un C++2 serait possiblement envisageable, mais pas une réécriture dans un langage qui ne partage rien en commun.
Un projet comme le noyau Linux est aussi le genre de projet qui pourrait bénéficier d’extensions du C, par exemple de nouveaux types qui, lorsque tu les utilises, te sortent des erreurs et t’obligent à porter en cascade le reste du code qui utilise ces variables et autres constructions.
ce commentaire est sous licence cc by 4 et précédentes
Ça c’est la question de la granularité. Firefox c’est près de 8 millions de lignes de code et 3,5 millions en rust (et 3,7 en C mais c’est peut être mal catalogué et ce serait 10 million de LOCs en C++).
Chaque projet a ses contraintes et ses besoins. La question c’est comment tu interface du code déjà mis à jour avec du code qui ne l’est pas. Il n’y a pas de solutions toute faite à ça.
Ce que tu dis ne fait que confirmer ce que je pense : un gros projet relativement récent, qui est toujours vivan et développé activement aura tout intérêt à ne pas être réécrit. Un vieux code qui n'est plus maintenu, écrit malproprement vaudra peut-être le coup d'être réécrit (on peut aussi vouloir changer la façon de faire comme par exemple le passage vers devfs puis vers udev, ou le passage de gnome2 à gnome3 qui a été une grosse rupture).
De ce que j'ai compris, la proposition, c'est juste de configurer ton compilo pour qu'il ne t'autorise pas à utiliser des syntaxes qui ne sont pas sûres (typiquement les for avec des indexes). Et t'aurais donc des "profiles" que tu pourrais sélectionner pour t'autoriser plus ou moins de trucs.
Je sais pas si j'ai loupé quelque chose, mais de loin, on dirait que ça casse pas trois pattes à un canard. (coin)
Avec C et le C++ c'est facile de faire planter un programme mais ça l'est tout autant en python qu'en rust. J'ai des programme en python qui ont planté, en rust aussi, bref. C'est sûr que que le C et le C++ ne sont pas parfait mais les compilateurs ont fait des efforts de dingue maintenant.
De plus les sanitizers et les linter statiques sont vraiment puissant qu'ils permettent de voir beaucoup de problèmes à la compilation et pendant le phase de dev.
Pour ma part, ça fait un bien grand moment que j'ai pas fait un buffer overflow.
git is great because linus did it, mercurial is better because he didn't
Avec C et le C++ c'est facile de faire planter un programme mais ça l'est tout autant en python qu'en rust.
Pour autant tout ne se vaut pas. Il faut hiérarchiser les problèmes. Plus tu attrape tôt un problème moins il est un problème. Dis autrement trouver un problème dans ton éditeur c’est mieux que le trouver en intégration et c’est mieux que le trouver en chez les utilisateurs.
Si tu dois faire un test pour vérifier que tu n’a jamais écrit "ma chaine" / 4, ça veut dire que tu dois y penser, écrire un test, le lancer etc. Si ton langage te l’interdit alors tu n’y pensera que très peu de temps au moment où tu va faire l’erreur et c’est tout.
De plus les sanitizers et les linter statiques sont vraiment puissant qu'ils permettent de voir beaucoup de problèmes à la compilation et pendant le phase de dev.
Du fait que la sémantique du langage n’a pas certaines informations, ils ont beaucoup plus de travail pour moins de résultats et t’indiquent le problème plus tardivement.
Pour ma part, ça fait un bien grand moment que j'ai pas fait un buffer overflow.
Est-ce que tu sais qu’il n’y en a pas ou est-ce qu’ils n’ont pas était trouvé ?
En tout cas cette année on en est à 120 CVE liées à des buffer overflow.
Est-ce que tu sais qu’il n’y en a pas ou est-ce qu’ils n’ont pas était trouvé ?
En plus de cela, le buffer overflow n'est pas la seule cause d'erreurs de mémoire qui est d'ailleurs peut être la plus simple à éviter avec de bonnes structures de données.
Par contre des race conditions, des deadlocks, des use after free (ou double free) dans un contexte multithread, etc. c'est assez courant (notamment dans le noyau Linux par exemple) et difficile à éviter. Si Rust ne peut pas empêcher toutes ces erreurs de survenir (notamment à cause des unsafe), le risque est bien plus réduit par défaut et le débogue plus facile quand ils surviennent.
# Article intéressant ...
Posté par totof2000 . Évalué à 8 (+6/-0).
La question si j'ai bien compris, est de patcher le C/C++ pour qu'il puisse gérer la mémoire de manière pluis sûre, parce que ce serait moins compliqué d'adapter le code existant à une nouvelle gestion mémoire que tout réécrire en rust … Ca se défend, mais je ne suis pas convaincu : ça dépendra surtout je pense de la façon dont le code a été écrit initialement. Pour du code écrit relativement récemment avec un respect de bonnes pratiques de dev, je pense que ça se tient. Pour du code plus ancien, je ne suis pas sûr que l'on y perde beaucoup à tout réécrire. Je pense que c'est du cas par cas.
Sinon je réagis à ceci :
Je pense que même les plus fervents défenseurs de Rust n'ont jamais prétendu que Rust était invulnérable. Par contre le fait que du code potentielement vulnérable soit dans des blcs "unsafe" spécifiquements déclarés permet de bien localiser ce code. En ne limitant les blocs unsafe qu'au strict nécessaire, on évite des erreurs d'inattention dans tout le reste du code.
Je n'ai pas compris en détail les solutions memory save envisagées pour C++ (j'ai laché le C++ depuis (trop) longtemps). Si quelqu'un pouvait expliquer ici les principes je lui serais très reconnaissant.
[^] # Re: Article intéressant ...
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Ben personnellement j’irai plutôt dans la direction d’adapter le code existant si possible. Par exemple le jeu Unvanquished c’est environ 20 000 lignes dans le moteur et près de 12 000 dans le jeu lui-même, sans compter certaines bibliothèques et autre outils que l’on maintient. Personne n’ira réécrire ça. D’ailleurs historiquement notre code a été porté de C vers le C++, et ça a été possible parce que tu peux commencer à compiler du C avec un compilateur C++ assez facilement avant de commencer à utiliser des choses qui n’existent que dans le C++. Un effort similaire pour porter progressivement vers un C++2 serait possiblement envisageable, mais pas une réécriture dans un langage qui ne partage rien en commun.
Un projet comme le noyau Linux est aussi le genre de projet qui pourrait bénéficier d’extensions du C, par exemple de nouveaux types qui, lorsque tu les utilises, te sortent des erreurs et t’obligent à porter en cascade le reste du code qui utilise ces variables et autres constructions.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Article intéressant ...
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Ça c’est la question de la granularité. Firefox c’est près de 8 millions de lignes de code et 3,5 millions en rust (et 3,7 en C mais c’est peut être mal catalogué et ce serait 10 million de LOCs en C++).
Chaque projet a ses contraintes et ses besoins. La question c’est comment tu interface du code déjà mis à jour avec du code qui ne l’est pas. Il n’y a pas de solutions toute faite à ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Article intéressant ...
Posté par totof2000 . Évalué à 3 (+1/-0).
Ce que tu dis ne fait que confirmer ce que je pense : un gros projet relativement récent, qui est toujours vivan et développé activement aura tout intérêt à ne pas être réécrit. Un vieux code qui n'est plus maintenu, écrit malproprement vaudra peut-être le coup d'être réécrit (on peut aussi vouloir changer la façon de faire comme par exemple le passage vers devfs puis vers udev, ou le passage de gnome2 à gnome3 qui a été une grosse rupture).
[^] # Re: Article intéressant ...
Posté par corentin38 (site web personnel) . Évalué à 3 (+2/-0).
De ce que j'ai compris, la proposition, c'est juste de configurer ton compilo pour qu'il ne t'autorise pas à utiliser des syntaxes qui ne sont pas sûres (typiquement les for avec des indexes). Et t'aurais donc des "profiles" que tu pourrais sélectionner pour t'autoriser plus ou moins de trucs.
Je sais pas si j'ai loupé quelque chose, mais de loin, on dirait que ça casse pas trois pattes à un canard. (coin)
# Aucun langage est parfait
Posté par David Demelier (site web personnel) . Évalué à 3 (+1/-0).
Avec C et le C++ c'est facile de faire planter un programme mais ça l'est tout autant en python qu'en rust. J'ai des programme en python qui ont planté, en rust aussi, bref. C'est sûr que que le C et le C++ ne sont pas parfait mais les compilateurs ont fait des efforts de dingue maintenant.
De plus les sanitizers et les linter statiques sont vraiment puissant qu'ils permettent de voir beaucoup de problèmes à la compilation et pendant le phase de dev.
Pour ma part, ça fait un bien grand moment que j'ai pas fait un buffer overflow.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Aucun langage est parfait
Posté par barmic 🦦 . Évalué à 7 (+5/-0).
Pour autant tout ne se vaut pas. Il faut hiérarchiser les problèmes. Plus tu attrape tôt un problème moins il est un problème. Dis autrement trouver un problème dans ton éditeur c’est mieux que le trouver en intégration et c’est mieux que le trouver en chez les utilisateurs.
Si tu dois faire un test pour vérifier que tu n’a jamais écrit
"ma chaine" / 4, ça veut dire que tu dois y penser, écrire un test, le lancer etc. Si ton langage te l’interdit alors tu n’y pensera que très peu de temps au moment où tu va faire l’erreur et c’est tout.Du fait que la sémantique du langage n’a pas certaines informations, ils ont beaucoup plus de travail pour moins de résultats et t’indiquent le problème plus tardivement.
Est-ce que tu sais qu’il n’y en a pas ou est-ce qu’ils n’ont pas était trouvé ?
En tout cas cette année on en est à 120 CVE liées à des buffer overflow.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Aucun langage est parfait
Posté par Renault (site web personnel) . Évalué à 6 (+3/-0).
En plus de cela, le buffer overflow n'est pas la seule cause d'erreurs de mémoire qui est d'ailleurs peut être la plus simple à éviter avec de bonnes structures de données.
Par contre des race conditions, des deadlocks, des use after free (ou double free) dans un contexte multithread, etc. c'est assez courant (notamment dans le noyau Linux par exemple) et difficile à éviter. Si Rust ne peut pas empêcher toutes ces erreurs de survenir (notamment à cause des unsafe), le risque est bien plus réduit par défaut et le débogue plus facile quand ils surviennent.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.