Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

462
Vistas
El operando de la derecha de un operador lógico || tiene efectos secundarios persistentes debido a la función de llamada (MISRA-C 2012Regla 13.5)

El operando de la derecha de un operador lógico || tiene efectos secundarios persistentes debido a la llamada a la función detectError() .

 if ( ( detect() == VALID ) || ( detectError() == INVALID ) ) { up( a,b ); }
 typedef enum { C; }E_name;
 typedef struct { E_name be:4; }S_name; S_name name;

persistent_side_effect: La expresión name.be = C tiene un efecto secundario persistente: modifica el objeto no local okay.be = C.

 sint16 detectError(void) { name.be = C; }

Pude resolver el operador lógico &&, ¿hay alguna solución para || ¿operador?

over 4 years ago · Santiago Trujillo
2 Respuestas
Responde la pregunta

0

Seguramente el trabajo más simple para esto es:

 whateverType detectFlag1 = detect(); whateverType detectFlag2 = detectError(); if ( ( detectFlag1 == VALID ) || ( detectFlag2 == INVALID ) ) { up( a,b ); }

¿Código simple y claro, sin posibles efectos secundarios?

over 4 years ago · Santiago Trujillo Denunciar

0

En general, el código con problemas de calidad de MISRA-C debe ser determinista y debe existir al menos un caso de uso en el que se ejecute alguna parte del código (cobertura de código). En este caso, no se sabe si se llama a detectError() o no, lo que puede o no ser problemático dependiendo de si esa función contiene algún efecto secundario.

Además, el sentido común no encaja bien con "si la detección es válida o la detección del error no es válida". ¿Qué se supone que significa eso, si la detección falló pero no pudo detectar errores, entonces eso no dejaría su programa en un estado indefinido?

Por supuesto, no tengo idea de qué están haciendo estas funciones, pero tal vez al menos considere una mejor denominación del identificador. Tal vez "detectar error" debería llamarse "obtener el último error" o algo así.

Suponiendo que el código es correcto, puede reescribirlo de una manera más clara pero equivalente a esta:

 if(detect() == VALID) { up(a, b); } else if(detectError() == INVALID) { up(a, b); } else { ; // possibly handle this scenario or leave it blank }

Tenga en cuenta que el else es obligatorio según el código de autodocumentación/programación defensiva de MISRA-C.


Otras preocupaciones:

  • Usar campos de bits en una aplicación MISRA-C es una muy mala idea. MISRA-C no los prohíbe, pero generalmente no son portátiles y están mal estandarizados, por lo que no pertenecen a un programa determinista o portátil.
  • No cree estándares de garaje caseros para números enteros como sint16 . Utilice C sint16_t estándar de stdint.h en su lugar. Si está atascado con C90, haga typedefs correspondientes a los nombres stdint.h .
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda