MISRA C++:2023 TC1:2026 : Ce que les équipes C++ embarquées doivent savoir

MISRA a publié le premier corrigenda technique pour MISRA C++:2023. Le TC1:2026 clarifie l'interprétation des règles, ajoute de nouvelles exceptions et ajuste la portée de l'analyse dans plusieurs directives. Pour plus de détails, consultez la suite et découvrez comment C/C++test prend pleinement en charge ces mises à jour.

À première vue, la norme MISRA C++:2023 TC1:2026 pourrait sembler relever d'une simple mise à jour éditoriale. Elle contient effectivement des corrections de formulation et d'exemples. Toutefois, les équipes de développement C++ embarqué devraient y porter une attention particulière.

Plusieurs mises à jour modifient la façon dont les directives existantes doivent être interprétées et appliquées, notamment de nouvelles exceptions, des modifications de la portée de l'analyse, une clarification des comportements conformes et non conformes, et une meilleure prise en compte des pratiques de programmation C++ modernes.

Cette distinction est importante lorsque la conformité à la norme MISRA est appliquée par le biais d'une analyse statique.

Les numéros des règles n'ont peut-être pas changé, mais dans certains cas, la manière dont ces règles doivent être appliquées a évolué.

Un analyseur n'ayant pas intégré les rectificatifs pourrait signaler du code désormais explicitement autorisé par TC1 ou ne pas prendre en compte des comportements clarifiés par la mise à jour des recommandations. Pour les équipes s'appuyant sur l'analyse automatisée dans le cadre d'un processus de développement critique pour la sûreté ou la sécurité, il est donc essentiel de se conformer à la dernière interprétation des recommandations afin de garantir la conformité à la loi MISRA.

Pourquoi la norme MISRA C++:2023 TC1 est importante

Les normes de codage évoluent inévitablement lorsqu'elles sont appliquées à des logiciels réels. Des ambiguïtés apparaissent, des exemples révèlent des cas limites et des modèles de programmation légitimes nécessitent parfois des éclaircissements supplémentaires.

Un erratum technique permet de remédier à ces problèmes sans remplacer la norme sous-jacente. Le comité technique TC1 procède précisément ainsi pour MISRA C++:2023, en fournissant les instructions éditoriales pour la mise à jour des recommandations vers MISRA C++:2023 (TC1:2026).

Certaines modifications sont relativement mineures, tandis que d'autres ont des implications directes sur l'analyse statique. Une construction auparavant considérée comme une violation peut désormais relever d'une exception définie, tandis que d'autres modifications précisent ce qu'un analyseur doit comprendre du comportement du programme pour déterminer correctement sa conformité.

Il arrive aussi que le périmètre d'analyse requis ait évolué. Ces mises à jour soulignent un point essentiel : une prise en charge efficace de MISRA ne se limite pas à la simple mise à disposition d'un vérificateur pour chaque règle. Ce vérificateur doit implémenter l'esprit et la sémantique actuels de la directive.

Voici à quoi ressemble le code réel de MISRA C++:2023 TC1

Plusieurs mises à jour de TC1 concernent des constructions de programmation que les développeurs rencontrent fréquemment dans le code C++ moderne. L'un des exemples les plus simples apparaît dans la règle 0.0.2, où TC1 introduit une exception autorisant une expression de contrôle résultant de l'expansion de la macro assert. Le corrigenda fournit spécifiquement assert(false && "Unexpected case") à titre d'exemple conforme à la nouvelle exception.

#include <cassert>

void handleUnexpectedCase()

{

    assert(false && "Unexpected case");  // Compliant by TC1 exception

}

Il s'agit d'une modification mineure aux conséquences concrètes. Un analyseur appliquant l'interprétation initiale sans tenir compte de l'exception TC1 pourrait signaler une violation pour une construction explicitement autorisée par la version mise à jour des directives MISRA. Ceci illustre l'importance de maintenir à jour l'implémentation d'une norme de codage : l'objectif n'est pas simplement de trouver davantage de violations, mais d'identifier les violations pertinentes.

La règle 0.1.1 est considérablement précisée. Son titre est mis à jour et indique désormais qu'« une écriture sur un objet local doit être nécessaire ».

TC1 définit plus précisément ce qui constitue une écriture nécessaire en fonction des occurrences le long des chemins d'exécution possibles. La mise à jour reconnaît également : [[maybe_unused]] Ces distinctions reflètent l'intention du développeur et précisent le traitement des types composites, des conteneurs, des boucles et des fonctions. Elles sont essentielles pour éviter les erreurs d'analyse où l'analyseur a techniquement identifié une écriture sans avoir correctement interprété l'utilisation de la valeur ou de l'objet correspondant.

La TC1 prend également mieux en compte les techniques de conception C++ établies. La règle 6.4.2, par exemple, prévoit une exception pour le modèle de conception « Curiously Recurring Template Pattern » (CRTP). Le corrigenda indique explicitement que la règle précédente interdisait indûment l'utilisation de ce modèle et autorise désormais la dissimulation de noms sous certaines conditions CRTP.

Voici un exemple simplifié de modèle CRTP :

template <typename Derived>

class Base

{

public:

    void interface()

    {

        static_cast(this)->implementation();

    }

};

class Device : public Base

{

public:

    void implementation()

    {

        // Device-specific behavior

    }

};

Cet exemple illustre le type de modèle CRTP visé par la nouvelle exception. Cela ne signifie pas que toute utilisation de CRTP est automatiquement conforme à MISRA. En réalité, TC1 corrige une situation où la formulation initiale pouvait interdire une technique C++ établie, même utilisée dans les conditions désormais définies par l'exception.

La règle 6.2.3 est également mise à jour afin d'autoriser les modèles courants et sûrs impliquant des spécialisations de modèles explicites et l'utilisation d'en-têtes. Ensemble, ces modifications illustrent un point important concernant MISRA C++ : le C++ critique pour la sécurité ne signifie pas éviter les constructions C++ modernes. Il s'agit de les utiliser de manière suffisamment comprise, encadrée et analysable pour garantir la fiabilité des logiciels.

Analyse plus précise du comportement du C++

D'autres modifications apportées à TC1 approfondissent la sémantique que l'analyseur doit comprendre. Les conversions et comparaisons numériques en sont un bon exemple.

• La règle 7.0.3 est clarifiée pour tenir compte des instructions switch et ajoute une exception permettant de convertir une expression de catégorie de caractères en void lorsqu'on ignore explicitement sa valeur.
• La règle 7.0.5 précise que la règle s'applique aux comparaisons telles que u8 == u8, tout en reconnaissant que la comparaison de valeurs de même type est sans risque. Elle corrige également les exemples qui comportaient auparavant des cas de promotion intégrale. est considérée comme sûre.

Le traitement des objets déplacés constitue un autre point important. Le TC1 révise en profondeur la règle 28.6.3 afin de préciser les cas où une variable peut potentiellement avoir un état déplacé, notamment pour les opérations impliquant `std::move`, `std::forward`, `std::move_if_noexcept` et les conversions équivalentes. Parallèlement, la mise à jour des recommandations reconnaît le comportement défini des objets `std::unique_ptr`, `std::shared_ptr` et `std::weak_ptr` en cas de déplacement.

C’est précisément là que l’analyse statique sophistiquée prend toute son importance. Se contenter de détecter la présence de `std::move` ne suffit pas. L’analyseur doit comprendre :

• L'état de la variable.
• Comment il est référencé par la suite.
• Si le type a défini une sémantique de déplacement.

L'objectif n'est pas de produire davantage de résultats, mais d'identifier les résultats qui sont réellement importants selon les directives.

Le périmètre de l'analyse est également important.

TC1 démontre également pourquoi l'analyse de conformité MISRA nécessite parfois une visibilité au-delà d'un fichier source individuel.

La règle 0.2.3 modifie son périmètre d'analyse requis, passant d'une unité de traduction unique à un système, et étend son traitement des types à visibilité limitée, y compris les membres privés, les alias de type, les modèles, les types de fermeture lambda, les énumérations et les unions anonymes.

Un analyseur limité à une seule unité de traduction peut donc ne pas disposer des informations nécessaires pour déterminer correctement cette règle.

Il est intéressant de noter que TC1 n'étend pas simplement le périmètre d'analyse à tous les éléments. La règle 21.6.4 va dans le sens inverse, en modifiant son périmètre d'application du système à l'unité de traduction unique, tout en précisant les exigences relatives aux fonctions de suppression d'opérateurs globaux, qu'elles soient dimensionnées ou non.

Ces modifications soulignent pourquoi un outil MISRA ne peut être évalué uniquement en se demandant s'il « prend en charge la règle X ». Il est plus pertinent de se demander si l'outil effectue le type d'analyse réellement requis par la règle X. La sémantique correcte des règles, la prise en compte du langage, le flux de données et de contrôle, ainsi qu'une portée d'analyse appropriée sont autant d'éléments qui contribuent à ce qu'un résultat obtenu reflète fidèlement les recommandations MISRA.

Que signifie TC1 pour votre outil d'analyse statique ?

Pour les organisations utilisant déjà MISRA C++:2023, TC1 soulève une question simple : votre outil d’analyse statique se contente-t-il de revendiquer une couverture MISRA C++:2023, ou son analyse reflète-t-elle la dernière interprétation des directives ?

Cette différence peut avoir des conséquences pratiques. Lorsque MISRA introduit une nouvelle exception, l'analyseur doit la reconnaître. Lorsque TC1 clarifie un comportement auparavant ambigu, le vérificateur doit appliquer cette clarification.

Lorsqu'un changement affecte le périmètre d'analyse d'une règle, l'analyse sous-jacente doit être modifiée en conséquence. Dans le cas contraire, les équipes de développement risquent de se retrouver face à des résultats inutiles, des violations non détectées, un travail supplémentaire de correction des écarts, ou encore une vérification manuelle pour compenser un comportement d'analyse obsolète.

Ceci est particulièrement important dans le cadre du développement de systèmes critiques pour la sécurité, où les résultats d'analyses statiques contribuent fréquemment à un ensemble plus vaste de preuves de conformité. Les équipes doivent avoir la certitude qu'une infraction signalée correspond à la directive en vigueur, et non à une interprétation qui a été corrigée ou clarifiée ultérieurement.

Parasoft C/C++test prend entièrement en charge la norme MISRA C++:2023 TC1.

Parasoft C/C++test prend pleinement en charge les modifications applicables introduites par MISRA C++:2023 TC1:2026. Cette prise en charge va au-delà de la simple mise à jour des descriptions de règles ou de la documentation. C/C++test implémente la sémantique des règles, les exceptions, les exigences d'analyse et les cas de conformité et de non-conformité mis à jour, tels que définis par les rectificatifs.

Pour les équipes de développement, cela évite la corvée de l'examen manuel des rectificatifs et de la détermination de l'impact de chaque modification sur l'analyse statique existante. Les développeurs peuvent ainsi continuer à appliquer l'analyse MISRA dans leurs environnements de développement intégrés (IDE) et leurs flux de travail CI/CD habituels, tout en se basant sur les dernières recommandations. Cela réduit les investigations inutiles sur des résultats basés sur des interprétations obsolètes, tout en garantissant le traitement correct des cas nouvellement clarifiés.

C/C++test intègre également l'analyse MISRA au processus global de vérification et de conformité. Les équipes peuvent ainsi identifier plus tôt les violations des normes de codage, les corriger dans le cadre du développement et de l'intégration continue, et produire les rapports et les preuves nécessaires pour démontrer la conformité. L'objectif n'est pas simplement d'exécuter un vérificateur MISRA, mais de faire de la conformité MISRA une pratique courante et systématique du développement logiciel.

Maintien de la conformité MISRA C++ à jour

MISRA C++:2023 TC1 ne remplace pas MISRA C++:2023. Il précise les recommandations en tenant compte des problèmes identifiés depuis leur publication. Pour les organisations développant des logiciels embarqués critiques, ces améliorations sont essentielles, car la précision de la norme doit se traduire par une précision dans l'analyse utilisée pour son application.

Un outil d'analyse statique doit donc comprendre bien plus que la seule règle MISRA applicable. Il doit prendre en compte l'interprétation la plus récente de cette règle, ses exceptions, le périmètre d'analyse requis et la sémantique C++ sous-jacente.

Grâce à sa prise en charge complète de MISRA C++:2023 TC1, C/C++test aide les équipes de développement à maintenir leur analyse MISRA à jour tout en continuant à tirer parti du C++ moderne dans les logiciels critiques pour la sûreté et la sécurité.

« MISRA », « MISRA C » et le logo triangulaire sont des marques déposées de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Tous droits réservés.