IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les détracteurs du Rust s'unissent autour de l'initiative Fil-C : Une implémentation sécurisée des langages C et C++
Destinée à redonner au langage C sa grandeur

Le , par Patrick Ruiz

11PARTAGES

6  0 
Le langage C est de plus en plus sujet à controverse comme en témoigne la situation tendue dans la communauté de développement du noyau Linux : les principaux mainteneurs sont des habitués du langage C et refusent de porter le code existant en C ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. En toile de fond, c’est la question de savoir si le langage C a besoin d’un remplaçant dans la filière de la programmation système qui est au centre des débats. C’est la raison de l’apparition d’implémentation dites sécurisées du langage C comme Fil-C.

« Les langages de programmation C et C++ sont merveilleux. Il existe une tonne de codes écrits dans ces deux langages. Mais le C et le C++ sont des langages peu sûrs. De simples erreurs de logique peuvent amener un attaquant à contrôler la zone mémoire un pointeur et ce qui y est écrit, ce qui ouvre la voie à une exploitation facile. Beaucoup d'autres langages (Rust, Java, etc.) n'ont pas ce problème ! Mais j'aime le C. Et j'aime presque autant le C++. J'ai grandi avec eux. C'est une telle joie pour moi de d'utiliser les deux ! C'est pourquoi, pendant mon temps libre, j'ai décidé de créer mes propres langages C et C++ à mémoire sécurisée. Il s'agit d'un projet personnel et d'une expression de mon amour pour le C. Fil-C introduit la sécurité de la mémoire au cœur du C et du C++ », souligne Filip Pizlo de Epic Games.

« Le projet vise une compatibilité à 100 % avec C et C++. Il suffit de compiler son code avec le compilateur pour obtenir du code sécurisé », d’après Pizlo. Ce dernier reconnaît néanmoins que « le principal obstacle à l'utilisation de Fil-C en production est la vitesse. Fil-C est actuellement environ 1,5 à 5 fois plus lent que le C traditionnel. »


L’initiative fait surface dans un contexte de multiplications des appels au passage à des langages de programmation dits sécurisés et Rust s’impose au point d’être adopté pour lé développement du noyau Linux

Linus Torvalds lui-même est pourtant d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Source : GitHub du projet

Et vous ?

Que pensez-vous de cette multiplication d’implémentations dites sécurisées du langage C ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ? Simple résistance au changement ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de NotABread
Membre habitué https://www.developpez.com
Le 18/11/2024 à 17:23
Citation Envoyé par vivid Voir le message
A toujours être assister on perd en compétence ! çà c'est un paradigme
[Troll]
Tu as raison, les IDE avec leurs suggestions automatiques et leur autres fioritures, les smart pointer, les class, les struct, les bibliothèques, les compilateurs et les éditeurs de lien... Que d'éléments qui nous obscurcissent de la vrai connaissance de la programmation ! Les vrais dev, eux ils font tout en assembleur et leur programmes marchent sans problème quelque soit l'ordinateur ou le temps
[/Troll]

Il faut savoir où mettre son cheval de bataille. Le temps passer à s'assurer que toutes les possibilités soient correctement traiter est de la productivité de perdu. Si l'on peut gagner en productivité et en stabilité tout en conservant les performances, pourquoi devrions refuser d'être assister ? Pour la beauté du geste ?
Attention, je ne dis pas qu'il ne faut pas savoir comment ça marche derrière, rien n'est magique et l'obscurantisme mènent à la dépendance. Je dis juste que rejeter toute assistance est idiot. Si le borrow checker de Rust me dit qu'il y a un risque d'un double emprunt, c'est pas lui qui à mal compris mon code, c'est moi qui n'a pas vu le cas où ça pourrait si produire. L'humain aussi assidu puisse t-il être ne sera jamais infaillible. Avoir l'assistance d'un programme l'aide à éviter des erreurs
2  0 
Avatar de Fagus
Membre expert https://www.developpez.com
Le 18/11/2024 à 10:50
C'est une compilation avec des bound checks et un garbage collector. Ça va pas plaire à tout le monde. En plus il faut modifier un peu les sources.
0  0 
Avatar de vivid
Membre habitué https://www.developpez.com
Le 18/11/2024 à 11:13
A toujours être assister on perd en compétence ! çà c'est un paradigme
3  3 
Avatar de NotABread
Membre habitué https://www.developpez.com
Le 18/11/2024 à 11:46
Que pensez-vous de cette multiplication d’implémentations dites sécurisées du langage C ?
Je ne suis pas contre, on a plusieurs idée explorée tel que "rustiser" C++ (je n'ai plus le nom du projet), ici ajouter un GC et des bound check ou encore (je ne suis pas vraiment sûr de ça) ajouter une notion d'ownership avec Zig. Peut-être que qu'une idée novatrice s'imposera, ou peut être que l'on aura un énième langage. La plus grosse contrainte est la compatibilité avec l'existant et je ne pense pas qu'il y a de solution miracle.

Pourquoi le langage C pourrait encore avoir de longues années devant lui ? Simple résistance au changement ?
Tout simplement parce qu'il y a une énorme base de code en C, tout transcripter en un langage à mémoire sûre demandera beaucoup de temps donc d'argent. Ajoutons aussi que la simplicité de C permet aussi d'écrire "facilement" un compilateur pour une plateforme personnalisée. C ne nous quittera pas de sitôt n'en déplaise à ses détracteurs.

Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Je dirai que oui, les cyberattaques sont de plus en plus sophistiquées, une petite erreur simple peut permettre un contrôle à distance et garantir qu'une énorme base de code sera 100% safe demande un temps monstrueux (amusez à faire de la preuve formelle avec coq sur absolument tout un programme, je suis presque sûr que ça sera plus long que de réécrire le code en un langage à mémoire sûre). On peut aussi compter le temps perdu pour débugguer un problème mémoire.
Ce n'est que mon avis, mais il faut un langage à mémoire sûr qui ne sacrifie pas significativement les performances. D'une part, cela garanti une absence de type de faille de facto, d'autre part, cela améliorera la productivité et permettra de se focaliser plus sur les aspects de logique et moins sur de la technique.

Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Est-ce de la faute du développeur de ne pas avoir prévu tous les cas possible et impossible ? Est-ce de la faute du manager d'avoir mit une deadline qui a réduit les campagnes de test ? Est-ce la faute de ces grandes entreprises qui font des bénéfices énormes sur les communautés libre et open source sans pour autant investir dans celle-ci pour améliorer le code ? Est-ce la faute du langage qui permet de se tire une balle dans le pied ?
La réponse est: un langage, c'est un choix technique et comme tout choix technique il y a des avantages et des inconvénients. Choisir le C c'est avoir de très bonne performance au prix de devoir gérer la mémoire soit même et les risque accrus d'un plantage ou de faille de sécurité. Je ne blâmerais ni les dev, ni le langage si leur programme plante tous les vendredi 13, soir de pleine lune lorsque tous les astres du systèmes solaires sont alignés.
0  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 18/11/2024 à 22:29
Citation Envoyé par vivid Voir le message
A toujours être assister on perd en compétence ! çà c'est un paradigme
Rassure toi, les règles d'emprunt, et les manières de faire avec de Rust nécessitent des compétences. Même si le compilateur est assez didactique dans son assistance.

Citation Envoyé par NotABread Voir le message
Je ne suis pas contre, on a plusieurs idée explorée tel que "rustiser" C++ (je n'ai plus le nom du projet), ici ajouter un GC et des bound check ou encore (je ne suis pas vraiment sûr de ça) ajouter une notion d'ownership avec Zig. Peut-être que qu'une idée novatrice s'imposera, ou peut être que l'on aura un énième langage. La plus grosse contrainte est la compatibilité avec l'existant et je ne pense pas qu'il y a de solution miracle.
Mais est-ce vraiment nécessaire de multiplier à outrance les langages ? L'intérêt d'un langage est aujourd'hui autant dans les qualités intrinsèques que dans l'écosystème autour (à commencer pour le côté batteries included). Le côté révélateur est marqué par les gestionnaires de packages qui permettent une fluidité dans l'accès à cet écosystème (Pip pour Python, Maven pour Java, Nuget pour C#, Cargo pour Rust, vcpkg pour C/C++/MSVC, Opam pour OCaml, Alire pour Ada, etc...).

Actuellement, on a des langages évolués, mais néanmoins avec des implémentations proches du matériels (Rust, Ada, Zig, D...). Ada est peut-être un des rares langages avec des types entiers bornés (comme range 1..10). L'avantage est que si une variable a ce type, inutile de tester les limites d'un tableaux de type array (range 1..10) of Integer. Un for I in Tableau'Range loop Tableau(I) := Tableau(I)*2; end loop; peut être compilé sans aucune vérification de bornes (sauf le *2... si on dépasse la capacité des Integer !! NB: Il y a des types sans vérifications de bornes), mais aussi sans aucun risque de sécurité. Par ailleurs, il existe des langages moins proches du matériels utilisés aussi dans des applications similaires (le projet MirageOS vise à proposer un Unikernel en OCaml).

Quand à ajouter à C/C++ un GC et des bound check, c'est peut-être ce qui est fait avec C# dans une certaine mesure. (Même si l'arithmétique des pointeurs y est autorisé uniquement pour des blocs unsafe).
0  0