Cela dit, si on passait à un langage plus haut niveau, j'espère qu'on pourrait intégrer la notion de sécurité par une approche haut-niveau dans le code, genre un sorte de "secured if" sous forme de fonction.
C'est ce à quoi je pensais avec les phantoms types. Très très grosso modo au lieu d'avoir un if, le code qui doit être exécuté en cas de sucés est une fonction dont l'argument n'est pas une string, mais un "pin valid" (c'est son type) et la seule manière d'obtenir une variable de ce type c'est de passer par la fonction qui vérifie le pin. Il me semble que ça peut protéger plus naturellement des problèmes dont tu parle, mais
si les compilateurs ne pensent pas à ce problème peut être qu'ils ne vont pas propager cette garantie dans le code généré, comme ils sont en mesure de vérifier statiquement tout ça en principe ils pourraient bien faire ce qu'ils veulent
s'ils le font mais pas tout le temps, tu ne peux pas (ou difficilement) reprendre la main sur le code généré pour corriger le problème (avoir un bout de code C ou assembleur)
C'est dommage je suis sûr qu'un compilateur pourrait implémenter cette sécurité :(
[^] # Re: Attaques hardware
Posté par barmic 🦦 . En réponse à la dépêche La voiture allergique à la glace à la vanille, et autres bugs. Évalué à 4.
C'est ce à quoi je pensais avec les phantoms types. Très très grosso modo au lieu d'avoir un if, le code qui doit être exécuté en cas de sucés est une fonction dont l'argument n'est pas une string, mais un "pin valid" (c'est son type) et la seule manière d'obtenir une variable de ce type c'est de passer par la fonction qui vérifie le pin. Il me semble que ça peut protéger plus naturellement des problèmes dont tu parle, mais
C'est dommage je suis sûr qu'un compilateur pourrait implémenter cette sécurité :(
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll