Si c'est possible de faire ça, et ça demanderait quand même sans doute des évolution pas neutre dans le langage parce que Rust s'appuie sur le système de type pour faire ça et des indications que le compilateur doit comprendre, et si tu veux garder une compatibilité, ça poserait le même type de problème que la distinction code "safe / unsafe" en rust.
Le code "unsafe" en Rust permet d'utiliser des pointeurs sans restrictions "à la C", mais l'approche de Rust est de limiter au maximum les sections "unsafe" dés le développement initial, pour avoir le maximum de trucs "tout bon" du point de vue sûreté mémoire dés le début. Si tu pars d'une base de code "toute unsafe" pour essayer de la rendre "safe" (en gardant la compatibilité C au max) tu te retrouves, intuitivement, à avoir le même problème que craignent certains mainteneurs du noyau Linux j'ai cru comprendre et à avoir à réécrire les API ou de grosses parties du code existant parce que les restrictions vont se propager dans le code dont il dépend, à la manière de la propagation des "async / await" dans du code qu'on veut rendre asynchrone dans certains langages comme le js. En plus velu parce que ça va rendre impossible l'utilisation de certaines constructions et peut être obliger à des changements d'architectures du code ou du gros refactoring.
Une autre approche serait d'utiliser des analyseurs statiques de code velus qui tentent de démontrer pleins de propriétés et ne pas laisser passer du code qui n'a pas ces propriétés. Mais ça pose sans doute le même type de pb de faire évoluer du code pré-existant vers plus de sûreté avec ce genre de techniques.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par thoasm . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 7.
C'est pas une question nouvelle Ce fil reddit d'il y a quelques années l'évoque, je lie une des réponses
Si c'est possible de faire ça, et ça demanderait quand même sans doute des évolution pas neutre dans le langage parce que Rust s'appuie sur le système de type pour faire ça et des indications que le compilateur doit comprendre, et si tu veux garder une compatibilité, ça poserait le même type de problème que la distinction code "safe / unsafe" en rust.
Le code "unsafe" en Rust permet d'utiliser des pointeurs sans restrictions "à la C", mais l'approche de Rust est de limiter au maximum les sections "unsafe" dés le développement initial, pour avoir le maximum de trucs "tout bon" du point de vue sûreté mémoire dés le début. Si tu pars d'une base de code "toute unsafe" pour essayer de la rendre "safe" (en gardant la compatibilité C au max) tu te retrouves, intuitivement, à avoir le même problème que craignent certains mainteneurs du noyau Linux j'ai cru comprendre et à avoir à réécrire les API ou de grosses parties du code existant parce que les restrictions vont se propager dans le code dont il dépend, à la manière de la propagation des "async / await" dans du code qu'on veut rendre asynchrone dans certains langages comme le js. En plus velu parce que ça va rendre impossible l'utilisation de certaines constructions et peut être obliger à des changements d'architectures du code ou du gros refactoring.
Une autre approche serait d'utiliser des analyseurs statiques de code velus qui tentent de démontrer pleins de propriétés et ne pas laisser passer du code qui n'a pas ces propriétés. Mais ça pose sans doute le même type de pb de faire évoluer du code pré-existant vers plus de sûreté avec ce genre de techniques.