Voici la réponse Sebastian dont je vous propose une traduction à la suite.
I completely agree with you, but you have to make some simplifications. I could do a whole presentation about the topic you're speaking of.
The audience however is full of C developers, and everybody who ever wrote some C knows that a memory unsafety in one place could show up somewhere completely different. Nonetheless, it is caused by a single "unsafe block" in the end.
Similarly, if your safe abstractions in Rust around unsafe code are leaky and broken, something completely different can explode later. But the bug itself is going to be in an unsafe block.
So, IMHO what I said is right (minus compiler/language bugs), just a big simplification that everybody who ever wrote code in a memory unsafe language should understand.
Je suis complètement d'accord avec toi, mais il est parfois nécessaire de passer par des simplifications. Je pourrais faire toute une présentation sur le sujet que tu évoques.
Le public [de la conférence GStreamer] est constitué de plein de développeurs C et tous ceux qui ont écrit du code C savent qu'une utilisation non sûre de la mémoire à un endroit donné peut ré-apparaître à un endroit totalement différent. Néanmoins, en fin de compte, le problème est bien provoqué par un bloc non sûr donné.
De la même façon, en Rust, si tes abstractions sûres basées sur du code non sûr fuient ou sont boguées, quelque chose de complètement différent risque d'exploser plus tard. Mais, le bug en lui-même se trouvera dans un bloc non sûr.
Donc selon moi, ce que j'ai dit est exact (mis à parts les bugs du compilateur ou du langage), c'est une grosse simplification que tous ceux qui écrivent du code dans un langage à gestion de la mémoire non sûre devraient comprendre.
[^] # Re: Rust vs. unsafe Rust
Posté par fengalin . En réponse au journal Conférence GStreamer 2017 : Oxydation de GStreamer. Évalué à 6.
Voici la réponse Sebastian dont je vous propose une traduction à la suite.
Je suis complètement d'accord avec toi, mais il est parfois nécessaire de passer par des simplifications. Je pourrais faire toute une présentation sur le sujet que tu évoques.
Le public [de la conférence GStreamer] est constitué de plein de développeurs C et tous ceux qui ont écrit du code C savent qu'une utilisation non sûre de la mémoire à un endroit donné peut ré-apparaître à un endroit totalement différent. Néanmoins, en fin de compte, le problème est bien provoqué par un bloc non sûr donné.
De la même façon, en Rust, si tes abstractions sûres basées sur du code non sûr fuient ou sont boguées, quelque chose de complètement différent risque d'exploser plus tard. Mais, le bug en lui-même se trouvera dans un bloc non sûr.
Donc selon moi, ce que j'ai dit est exact (mis à parts les bugs du compilateur ou du langage), c'est une grosse simplification que tous ceux qui écrivent du code dans un langage à gestion de la mémoire non sûre devraient comprendre.