Ton commentaire est intéressant, mais tu présentes les choses de manière un peu provocante dans cette phrase:
De là à appuyer tout l'argumentaire de Rust sur "les programmes écrits en C et C++ peuvent planter, un code écrit en Rust ne peut pas planter", je trouve que ça méritait quelques précisions
L'interview parle plutôt de bugs étranges et de failles de sécurité, plutôt du fait que ça ne plante jamais. Par exemple à propos de C/C++:
Vous pouvez facilement faire quelque chose qui fera planter votre système et permettra à un attaquant de prendre le contrôle de la machine de l’utilisateur, sans même vous rendre compte que ce que vous avez écrit n’est pas sûr.
Ça va juste échouer à l’exécution avec des symptômes bizarres.
Et dans ton cas il n'y a ni de faille de sécurité (enfin jusqu'à preuve du contraire), ni de symptôme bizarre (un message nous indique clairement le problème—en revanche oui le SIGILL est pour le moins déroutant j'avoue).
Et quand le texte dit qu'un programme Rust ne plante pas, il se ravise aussitôt:
Ce qui veut dire que si vous ne sortez pas du bac à sable, votre programme ne plantera pas... Du moins, il ne produira pas d’erreur de segmentation.
(et on n'a pas une erreur de segmentation :) )
J'ajouterai qu'il s'agit d'un problème dont les créateurs de Rust sont au courant (tu nous donnes justement les liens qui vont bien) qui devrait être réglé à terme, et pas d'une limite intrinsèque et insoluble du langage (comme l'obligation d'avoir des pauses dans un langage basé sur un GC par exemple).
Mais comme tu le soulignes le terme "sûr" qu'utilise Rust n'est pas sans ambiguïté ; il s'agit de cohérence des données (pas de pointeur qui écrit au pif dans la mémoire, ou de data-race entre 2 threads par exemple), pas du fait qu'un programme ne va pas terminer prématurément. Par exemple, il est souvent dit qu'il n'y pas de fuite mémoire avec Rust ; en fait c'est faux. La gestion mémoire est certes très bonne, mais par exemple il est possible lorsqu'on utilise du comptage de référence (on en a besoin dans certains cas) de "perdre" de la mémoire si on a des cycle de références. C'est bien dommage, mais ça ne rentre pas en contradiction avec la définition de sûreté du langage (le programme pourra finir par être à court de mémoire comme dans ton cas, mais ça n'introduira pas de faille de sécurité par exemple).
[^] # Re: Pas encore de gestion des erreurs d'allocation mémoire
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Conférence GStreamer 2017 : Oxydation de GStreamer. Évalué à 7.
Ton commentaire est intéressant, mais tu présentes les choses de manière un peu provocante dans cette phrase:
L'interview parle plutôt de bugs étranges et de failles de sécurité, plutôt du fait que ça ne plante jamais. Par exemple à propos de C/C++:
Et dans ton cas il n'y a ni de faille de sécurité (enfin jusqu'à preuve du contraire), ni de symptôme bizarre (un message nous indique clairement le problème—en revanche oui le SIGILL est pour le moins déroutant j'avoue).
Et quand le texte dit qu'un programme Rust ne plante pas, il se ravise aussitôt:
(et on n'a pas une erreur de segmentation :) )
J'ajouterai qu'il s'agit d'un problème dont les créateurs de Rust sont au courant (tu nous donnes justement les liens qui vont bien) qui devrait être réglé à terme, et pas d'une limite intrinsèque et insoluble du langage (comme l'obligation d'avoir des pauses dans un langage basé sur un GC par exemple).
Mais comme tu le soulignes le terme "sûr" qu'utilise Rust n'est pas sans ambiguïté ; il s'agit de cohérence des données (pas de pointeur qui écrit au pif dans la mémoire, ou de data-race entre 2 threads par exemple), pas du fait qu'un programme ne va pas terminer prématurément. Par exemple, il est souvent dit qu'il n'y pas de fuite mémoire avec Rust ; en fait c'est faux. La gestion mémoire est certes très bonne, mais par exemple il est possible lorsqu'on utilise du comptage de référence (on en a besoin dans certains cas) de "perdre" de la mémoire si on a des cycle de références. C'est bien dommage, mais ça ne rentre pas en contradiction avec la définition de sûreté du langage (le programme pourra finir par être à court de mémoire comme dans ton cas, mais ça n'introduira pas de faille de sécurité par exemple).