T'a le gros des dépendances utilisé, par la plupart des projets C.
J'ai ri, c'est tellement divers en pratique.
Mais tu dépasses rarement la 10éne de libs.
Cela dépend des projets. Puis vu la taille des libs dont tu parles plus haut, cela n'a pas forcément beaucoup de sens de comparer quelques mini libs Rust avec de grosses libs C ou C++.
En C t'a souvent des libs à tout faire, et rien que SDL, t'a des htable, des threads, une gestion du filesystem.
Tu dis que c'est un avantage, mais c'est aussi un inconvénient : surface d'attaque plus grande, réinvention de la roue avec risque de bogues ou de failles en plus.
C'est d'ailleurs le problème en C, le peu d'abstraction offerte oblige à réinventer des structures de données élémentaires tout le temps. Code dupliqué, code moins bien testé, avec des garanties de sécurité ou d'utilisation plus faibles, etc.
Alors oui tu t'épargnes une lib parfois en le faisant à la main, mais tu perds aussi à côté.
Si tu considères que chaque libs maintenues pas une personne différente est un vecteur d'attaque pour des supply-chaines attaques, Rust est juste plus vulnérable.
Cela reste à démontrer.
Tu noteras que les problèmes du C sont connus, bien documentés et malgré tout avec les années on a toujours un taux de faille élevé dans un domaine qui pourrait être réduit à presque zéro dans d'autres langages. Les attaques de supply chain contre Rust ne semblent pas plus élevés en pratique que ce qu'on a connu pour le C ou C++ à ce jour.
Car c'est beau aussi la théorie mais il faut constater en pratique, les soucis de mémoire en C ce n'est pas juste de la théorie, c'est ce qu'on mesure en vrai malgré l'évolution des bonnes pratiques, de l'outillage, etc.
[^] # Re: Petite question à ceux qui "baignent" encore dans le C
Posté par Renault (site web personnel) . En réponse au journal Vulnérabilités multiples dans sudo-rs. Évalué à 5.
J'ai ri, c'est tellement divers en pratique.
Cela dépend des projets. Puis vu la taille des libs dont tu parles plus haut, cela n'a pas forcément beaucoup de sens de comparer quelques mini libs Rust avec de grosses libs C ou C++.
Tu dis que c'est un avantage, mais c'est aussi un inconvénient : surface d'attaque plus grande, réinvention de la roue avec risque de bogues ou de failles en plus.
C'est d'ailleurs le problème en C, le peu d'abstraction offerte oblige à réinventer des structures de données élémentaires tout le temps. Code dupliqué, code moins bien testé, avec des garanties de sécurité ou d'utilisation plus faibles, etc.
Alors oui tu t'épargnes une lib parfois en le faisant à la main, mais tu perds aussi à côté.
Cela reste à démontrer.
Tu noteras que les problèmes du C sont connus, bien documentés et malgré tout avec les années on a toujours un taux de faille élevé dans un domaine qui pourrait être réduit à presque zéro dans d'autres langages. Les attaques de supply chain contre Rust ne semblent pas plus élevés en pratique que ce qu'on a connu pour le C ou C++ à ce jour.
Car c'est beau aussi la théorie mais il faut constater en pratique, les soucis de mémoire en C ce n'est pas juste de la théorie, c'est ce qu'on mesure en vrai malgré l'évolution des bonnes pratiques, de l'outillage, etc.