Un changement dans la gestion du code non sécurisé
Richard Lander, responsable produit de la plateforme .NET chez Microsoft, a détaillé dans un billet technique les intentions de l'équipe en matière de sécurité mémoire pour le langage C#. L'objectif est d'améliorer la sûreté du langage sans le transformer en un calque de Rust, et surtout sans renoncer au ramasse-miettes qui caractérise l'environnement .NET.
Actuellement, le mot-clé « unsafe » permet d'écrire du code bas niveau (pointeurs, accès mémoire non supervisé) à l'intérieur d'un programme C#. Ce mécanisme existe depuis la première version du langage, conçu par Anders Hejlsberg. De nombreux développeurs ne l'utilisent jamais, mais il reste indispensable pour l'interopérabilité avec le système d'exploitation, l'accès à des périphériques mappés en mémoire ou la mise en œuvre de routines critiques en termes de temps d'exécution.
Un nouveau modèle pour le mot-clé « unsafe »
À partir de C# 16, le comportement du mot-clé évolue. Selon la proposition de langage publiée sur le dépôt GitHub de l'équipe, marquer une méthode comme « unsafe » aura désormais pour effet de la marquer également comme « requires-unsafe » (nécessite un contexte non sécurisé). Cela signifie que tout appelant devra se trouver lui-même dans un contexte unsafe, et qu'une surcharge ne pourra pas être unsafe si la méthode de base est sûre.
Cette propagation en cascade vise à rendre plus explicite le recours au code dangereux. Un développeur pourra toutefois supprimer cette propagation en incluant un bloc unsafe à l'intérieur de sa méthode, sans marquer la méthode elle-même comme unsafe. Ce choix a suscité des interrogations : certains observateurs estiment qu'il serait plus clair d'utiliser un modificateur « safe » pour indiquer explicitement qu'une méthode est sécurisée, plutôt que de se reposer sur l'absence de « unsafe ». Richard Lander a indiqué qu'il défendait cette approche auprès de l'équipe de conception.
Calendrier de déploiement
Ces changements seront introduits dans C# 16, soit deux versions après l'actuelle (C# 14). Le cycle annuel de .NET prévoit la sortie de .NET 12, une version avec support à long terme (LTS), fin 2027. Une version préliminaire sera disponible en aperçu dans C# 15 et .NET 11, ce qui permettra aux développeurs de tester le nouveau modèle avant son adoption définitive.
L'équipe .NET a précisé que l'objectif est de faire de C# un langage choisi et reconnu pour son application stricte de la sécurité de type et de mémoire, tout en conservant sa productivité et sa simplicité d'usage.
Une inspiration Rust sans la révolution
Ce projet s'inscrit dans la volonté plus large de Microsoft d'améliorer la sûreté de ses langages de programmation, en particulier pour les parties du code qui interagissent avec le système d'exploitation ou les périphériques. Sans copier le modèle de propriété de Rust, qui impose des règles strictes de gestion de la mémoire, Microsoft choisit de renforcer les garde-fous existants. Le nouveau mécanisme de propagation du mot-clé « unsafe » devrait ainsi réduire les risques d'introduction de vulnérabilités mémoire tout en maintenant la flexibilité offerte par le ramasse-miettes.
Les développeurs C# peuvent s'attendre à une transition progressive : les pratiques actuelles resteront valables jusqu'à l'arrivée de la version 16, mais les nouvelles lignes directrices de l'équipe .NET encouragent d'ores et déjà une utilisation plus restrictive du code non sécurisé.
