Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

264
Views
Error MISRA-C en la inicialización de matriz de estructura

tengo lo siguiente:

 typedef struct { uint8_t BlockID; uint32_t Copies; uint16_t Size; }NVMM_ConfigType; const NVMM_ConfigType NvmmCnf_Layout[6] = { { 1, 1, 4}, { 2, 3, 4}, { 5, 5, 16}, { 10, 1, 4}, { 11, 2, 32}, { 13, 1, 100}, };

Lo cual me parece bien, pero MISRA-C está dando el siguiente error:

MISRA C:2012 regla 10.3 violación: [R] El valor de una expresión no se asignará a un objeto con un tipo esencial más estrecho o de una categoría de tipo esencial diferente

He tratado de averiguar por qué sucede esto, pero puedo verlo. Además, los resultados de compilación están plagados de errores en situaciones similares y no sé por qué.

¿Alguien sabe lo que está pasando?

EDITAR: también he intentado emitir explícitamente todos los valores y sigo recibiendo el mismo error:

 const NVMM_ConfigType NvmmCnf_Layout[6] = { { (uint8_t)1, (uint32_t)1, (uint16_t)4}, { (uint8_t)2, (uint32_t)3, (uint16_t)4}, { (uint8_t)5, (uint32_t)5, (uint16_t)16}, { (uint8_t)10, (uint32_t)1, (uint16_t)4}, { (uint8_t)11, (uint32_t)2, (uint16_t)32}, { (uint8_t)13, (uint32_t)1, (uint16_t)100}, };
over 4 years ago · Santiago Trujillo
3 answers
Answer question

0

(Hola, esta es una cuenta nueva, así que todavía no puedo usar la sección de comentarios para pedir más aclaraciones, así que disculpe la larga respuesta)

Para ser específicos, esta Regla 10.3 se refiere a MISRA-C:2012 (el estándar más reciente), que es una gran mejora con respecto a las versiones anteriores en el sentido de que se hace más esfuerzo para explicar el fundamento de MISRA, junto con muchos más ejemplos de cumplimiento y no cumplimiento.

El fundamento de la regla es: dado que C permite que las asignaciones entre diferentes tipos aritméticos se realicen automáticamente, el uso de estas conversiones implícitas puede conducir a resultados no deseados, con la posibilidad de pérdida de valor, signo o precisión. MISRA_C:2012 tiene un modelo de tipo esencial para ayudar a advertir cuando esto podría ocurrir.

Las descripciones de las reglas también incluyen excepciones a la regla. Para la Regla 10.3, una excepción es: Una expresión constante entera no negativa de tipo esencialmente con signo puede asignarse a un objeto de tipo esencialmente sin signo si su valor puede representarse en ese tipo.

No está claro cuál es la línea y la columna exactas en las que su herramienta informa la infracción (debería). La mejor de las herramientas también proporcionará información más detallada sobre exactamente qué parte de la regla se está violando (por ejemplo, si en lugar de un 1, tenía 128 en la primera asignación a un 8 bits, la herramienta debería ser muy explícita al respecto). ).

En cualquier caso, no veo (ni mi herramienta) ninguna violación de 10.3 aquí.

Dado que esta es una regla "decidible", me preocuparía la herramienta si se trata de un código crítico para la seguridad, además del hecho de que le está haciendo perder el tiempo.

La mayoría de las herramientas le permiten suprimir una advertencia y documentar el motivo (en este caso, se trata de un error en la herramienta).

Si su proveedor de herramientas necesita más información, puede publicar su pregunta en el foro de discusión en http://www.misra-c.com para obtener la respuesta oficial y reenviarla al proveedor.

over 4 years ago · Santiago Trujillo Report

0

Hmm, esa regla hará que la configuración de registros de 8 bits sea realmente imposible, ya que las operaciones aritméticas se realizan como int o más grandes ( conversiones aritméticas habituales ). Una razón más para rechazar MISRA como estándar de codificación.

Supongo que debe convertir cada valor individual en el inicializador al tipo del campo respectivo. Pero como se cita la regla, eso seguiría siendo una violación.

over 4 years ago · Santiago Trujillo Report

0

Cuando uso PC-Lint para verificar las reglas de Misra, a menudo necesito agregar el sufijo u a las constantes:

 const NVMM_ConfigType NvmmCnf_Layout[6] = { { 1u, 1u, 4u}, { 2u, 3u, 4u}, { 5u, 5u, 16u}, { 10u, 1u, 4u}, { 11u, 2u, 32u}, { 13u, 1u, 100u}, };

Esto elimina la conversión de int a unsigned .

Si esto no es suficiente, lanza:

 const NVMM_ConfigType NvmmCnf_Layout[6] = { { (uint8_t ) 1u, 1u, (uint16_t ) 4u}, { (uint8_t ) 2u, 3u, (uint16_t ) 4u}, { (uint8_t ) 5u, 5u, (uint16_t ) 16u}, { (uint8_t )10u, 1u, (uint16_t ) 4u}, { (uint8_t )11u, 2u, (uint16_t ) 32u}, { (uint8_t )13u, 1u, (uint16_t )100u}, };
over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!