Je ne suis pas développeur dans le noyau Linux et si je peux éviter de faire du C, j'en suis très content. Je n'ai donc pas de "il faudrait" à leur donner ou personne à convaincre. Siequelqu'un proposait l'intégrationde code Rust dans un projet auquel je participe (disons: Haiku), ça ferait par contre partie des questions que je vais poser afin de me faire un avis sur la question [il y en aurait plein d'autre, par exemple dans le cas de Haiku ce serait un problème pour le portage motorola 68000 qu'il faudrait officiellement abandonner dans l'état actuel des toolchains Rust). J'ai juste posé une question: quels sont les motifs utilisés dans le code du noyau Linux qui ne se prêteraient pas à un interfaçage avec Rust?
Avec une réponse à cette question, je pourrais apprendre des choses sur les limites de Rust et sur d'autres façons de gérer la mémoire, ou juste redécouvrir des façons de faire auxquelles je n'ai pas pensé. Ou peut-être que ce sema l'occasion de découvrir une interface qui est, en fait, mal définie. Je sais que dans Haiku, on a plein d'endroits où la resposabilité de libérer de la mémoire pointée par un pointeur est implicite et pas documentée, et il faut aller lire le code source pour vérifier, et en plus ce n'est pas forcément cohérent d'un objet à l'autre. Bien sûr c'est un problème qui peut être résolu oe plein de façons: avec du C++ "moderne" et des smart pointers, avec de la documentation, avec des outils d'analyse statique, ... mais l'approche de Rust de vérifier ça à la compilation semble quand même être une très bonne idée?
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 10.
Je ne suis pas développeur dans le noyau Linux et si je peux éviter de faire du C, j'en suis très content. Je n'ai donc pas de "il faudrait" à leur donner ou personne à convaincre. Siequelqu'un proposait l'intégrationde code Rust dans un projet auquel je participe (disons: Haiku), ça ferait par contre partie des questions que je vais poser afin de me faire un avis sur la question [il y en aurait plein d'autre, par exemple dans le cas de Haiku ce serait un problème pour le portage motorola 68000 qu'il faudrait officiellement abandonner dans l'état actuel des toolchains Rust). J'ai juste posé une question: quels sont les motifs utilisés dans le code du noyau Linux qui ne se prêteraient pas à un interfaçage avec Rust?
Avec une réponse à cette question, je pourrais apprendre des choses sur les limites de Rust et sur d'autres façons de gérer la mémoire, ou juste redécouvrir des façons de faire auxquelles je n'ai pas pensé. Ou peut-être que ce sema l'occasion de découvrir une interface qui est, en fait, mal définie. Je sais que dans Haiku, on a plein d'endroits où la resposabilité de libérer de la mémoire pointée par un pointeur est implicite et pas documentée, et il faut aller lire le code source pour vérifier, et en plus ce n'est pas forcément cohérent d'un objet à l'autre. Bien sûr c'est un problème qui peut être résolu oe plein de façons: avec du C++ "moderne" et des smart pointers, avec de la documentation, avec des outils d'analyse statique, ... mais l'approche de Rust de vérifier ça à la compilation semble quand même être une très bonne idée?