¿Cómo creo un módulo en MISRAC: 2012 que sigue a Dir 4.12 y 4.8?

Esta pregunta se relaciona con la encoding en ISO C99 siguiendo las pautas de MISRAC: 2012.

Estoy buscando orientación en Dir 4.8 “Si un puntero a una estructura o unión nunca se hace referencia en una unidad de traducción, entonces la implementación del objeto debería estar oculta” junto con Dir 4.12 “La asignación de memoria dinámica no se utilizará”.

Cuando se implementa un tipo de datos abstractos en C, es común referirse al ADT utilizando un controlador que es un puntero a una estructura que describe el estado interno del ADT. Esto se puede hacer usando un puntero opaco según Dir 4.8 con la ventaja de que los detalles internos permanecen ocultos para el usuario.

En general, más de uno de estos ADT podría existir, por lo que debe haber una manera de crear múltiples manejadores. Esto se puede resolver mediante la asignación de memoria para los detalles internos a los que hace referencia el manejador en una función de inicialización, sin embargo, esto no está permitido en Dir 4.12.

Otra opción es que la rutina de inicialización reciba un puntero a un identificador asignado de forma estática provisto por el usuario, sin embargo, esto no se puede lograr utilizando punteros opacos.

Ilustro el problema de abajo.

Module.h struct module; typedef struct module module_t; /* Module handle is only available to the world as an incomplete type. This allows us to satisfy MISRAC 2012 Dir 4.8.*/ Module.c #include "module.h" struct module { uint8_t value; }; module_t* module_get_a_handle(void) { return (module_t*)malloc(sizeof(struct module)); /* MISRAC 2012 Dir 4.12 disallows dynamic memory allocation.*/ } User.c #include "module.h" module_t* module_handle; module_handle = module_get_a_handle(); 

El problema también se describe en esta pregunta Asignación estática de tipos de datos opacos , sin embargo, no se discute con respecto a las directrices MISRAC: 2012.

Una solución descrita es utilizar un grupo de controladores asignados estáticamente que están disponibles para el código del cliente. Esta solución parece ser técnicamente compatible; sin embargo, parece que el concepto de asignación de memoria dinámica todavía existe aquí. Yo diría que aunque los manejadores están asignados estáticamente, el comstackdor no puede determinarlo durante la comstackción si habrá suficientes manejadores disponibles para que el software funcione correctamente.

Mi solución a este problema sería escribir una desviación alrededor de Dir 4.8 y usar punteros no opacos y una convención de nomenclatura fuerte que deje en claro a los usuarios que los detalles internos del ADT no deben cambiarse.

Tengo curiosidad por saber si existe un método bien aceptado para resolver este problema que satisfaga a Dir 4.8 y Dir 4.12, y no infringe ninguna otra regla de MISRAC: 2012. Cualquier comentario sería muy apreciado.

Parece que ha entendido tanto el problema como la solución: use un grupo de memoria estática desde dentro de cada ADT.

Sin embargo, esta agrupación debe restringirse a un cierto límite máximo, que debe estar codificado. Esencialmente, implementará el grupo como un búfer static en el scope del archivo y mantendrá un registro del tamaño “asignado” con una variable de contador. Para cada elemento que agregue, usted compara el contador con el límite máximo.

En caso de que se quede sin espacio, su progtwig lo sabrá y podrá manejar ese error de manera segura. Sin embargo, nunca debería haber una razón por la que te quedas sin espacio. Eso significaría que tienes un error de diseño. Es casi seguro que debería poder asegurarse de que no se quede sin espacio en tiempo de comstackción. O si no, al menos durante las pruebas de cobertura de código.


La directiva 4.12 se refiere a la asignación de memoria dinámica en el montón con malloc/free . El uso de esas funciones y el montón, es la definición estándar de facto del término asignación dinámica de memoria. No significa nada más.

Hay múltiples problemas con la asignación dinámica: tiempo de asignación no determinista, segmentación, memory leaks, etc.

La “dinámica” en sí misma no es una preocupación, siempre que el comportamiento del progtwig siga siendo determinista. Los estándares de seguridad siempre están preocupados por la asignación de memoria dinámica en el montón, porque implica un comportamiento no determinista, que es un pecado fundamental en el diseño de software crítico para la seguridad.

Para muchos sistemas embebidos comunes, como las aplicaciones de microcontroladores RTOS / metal descubierto, la asignación dinámica simplemente no tiene ningún sentido en absoluto .


Así que la agrupación de memoria estática no es “asignación de memoria dinámica”. De lo contrario, el uso de la stack también contaría como “memoria dinámica” y no sería posible escribir ningún software útil.