Misra C++:2023

Artículo original ↗ Discusión en Hacker News ↗

MISRA C++:2023, una directriz de pago para usar C++17 en sistemas embebidos críticos para la seguridad (especialmente automoción), suscita debate sobre su valor, alcance e impacto práctico. Los comentaristas la describen como un subconjunto más estricto y seguro de C++ que mejora la versión de 2008 y se alinea con AUTOSAR C++14, pero los críticos sostienen que algunas reglas son contraproducentes, van por detrás del estándar ISO y benefician sobre todo a los proveedores de herramientas de cumplimiento. Gran parte de la discusión se centra en el manejo de excepciones, la memoria dinámica, la cualificación de herramientas para normas como ISO 26262 y la disponibilidad limitada de analizadores estáticos de código abierto que den soporte completo a las nuevas reglas.

Resumen de MISRA C++:2023

  • Directrices para usar C++17 en sistemas críticos/de seguridad (especialmente automoción/embebidos).
  • Define qué características y prácticas del lenguaje están permitidas, restringidas o prohibidas para mejorar la previsibilidad, la seguridad y la fiabilidad.
  • Se considera una mejora importante respecto a MISRA C++:2008 y está fuertemente influida por AUTOSAR C++14.

Relación con los estándares de C++ y otras directrices

  • Se orienta a C++17 aunque existan estándares de C++ más recientes; algunos comentaristas señalan que muchas cadenas de herramientas aún se están poniendo al día, por lo que esto es aceptable en contextos críticos para la seguridad.
  • En comparación con otros estándares de codificación: SEI CERT C se describe como “cómo usar X de forma segura”, mientras que MISRA tiende a prohibir o restringir estrictamente las APIs peligrosas.
  • Algunos señalan alternativas libres de regalías (por ejemplo, una guía japonesa de codificación embebida), pero estas están mayoritariamente centradas en C y son menos útiles para C++.
  • Una visión: cada una de estas directrices define efectivamente un “lenguaje subconjunto”, contribuyendo a la fragmentación de C/C++.

Herramientas, licencias y código abierto

  • El estándar cuesta dinero y no es un estándar abierto; algunos sugieren que esto desalienta las herramientas FOSS.
  • Los ecosistemas de análisis estático están dominados por herramientas propietarias; pocas herramientas abiertas dan buen soporte a MISRA.
  • Se menciona a analizadores de código abierto (por ejemplo, NaiveSystems Analyze, Cppcheck, reglas basadas en CodeQL), pero la cobertura y el soporte de versiones pueden ir con retraso o estar repartidos entre ediciones comunitarias y de pago.

Excepciones, memoria dinámica y gestión de errores

  • La memoria dinámica está prohibida en MISRA C++:2023; sorprendentemente, las excepciones están permitidas e incluso recomendadas para cumplir las reglas.
  • El debate es intenso:
    • A favor de las excepciones: esenciales para una propagación de errores sensata en sistemas grandes o multihilo; ayudan con RAII e invariantes.
    • En contra de las excepciones: problemáticas en embebidos por el tamaño del código, el rendimiento, la determinismo y las limitaciones de la cadena de herramientas; muchos grandes proyectos C++ y sistemas embebidos las desactivan.
  • Desactivar las excepciones (-fno-exceptions) puede reducir el tamaño del binario, pero interactúa mal con la biblioteca estándar, lo que puede llevar a UB o a depender del comportamiento no especificado de std::terminate.

Contexto automotriz y crítico para la seguridad

  • MISRA suele aplicarse a ECU críticas para la seguridad (motor, frenos, airbags, etc.), no al infoentretenimiento.
  • Algunos critican la calidad del software automotriz, pero la mayoría coincide en que MISRA no es el problema principal; el proceso, la gestión, la subcontratación, AUTOSAR y la complejidad son problemas mayores.
  • La cualificación de herramientas y el cumplimiento de ISO 26262 son restricciones importantes; usar compiladores convencionales en código crítico para la seguridad requiere mucha documentación y pruebas.

C++ frente a “lenguajes seguros”

  • Algunos argumentan que la complejidad de C++ y el comportamiento indefinido lo hacen fundamentalmente inadecuado para la seguridad, sugiriendo Rust como un “C++ seguro”.
  • Otros proponen ideas de “MISRA para Rust” y señalan que incluso en lenguajes más seguros, las guías de estilo y los subconjuntos seguirían siendo valiosos.