1.

Un entorno estándar C

Regla 1.1 (Necesaria) : El programa no contendrá ninguna violación de la sintaxis y las restricciones
de la norma C, y no excederá los límites de traducción de la implementación.

Excepto cuando se utiliza una extensión de lenguaje, un programa no deberá:

• Contener cualquier violación de la sintaxis del lenguaje descrita en The Standard;

• Contener cualquier violación de las restricciones impuestas por The Standard.

Un programa no deberá exceder los límites de traducción impuestos por la implementación.

Nota: una implementación conforme genera un diagnóstico de sintaxis y violaciones de

restricciones, pero debe

consciente de que:

• El diagnóstico no necesariamente debe ser un error, sino que podría ser, por ejemplo, una
advertencia;

• El programa puede ser traducido y un ejecutable generado a pesar de la presencia de un

sintaxis o violación de restricciones;

Nota: una implementación conforme no necesita generar un diagnóstico cuando un límite de

traducción es

excedido; Se puede generar un ejecutable pero no se garantiza que se ejecute correctamente.

Algunos compiladores de C90 brindan soporte para funciones en línea utilizando la palabra clave
__inline. Un programa C90

que use __inline cumplirá con esta regla, siempre que esté diseñada para traducirse usando

Tal compilador.

Muchos compiladores para objetivos incrustados proporcionan palabras clave adicionales que
califican los tipos de objeto con

atributos del área de memoria en la que se encuentra el objeto, por ejemplo:

• __zpage: se puede acceder al objeto mediante una breve instrucción

• __near: un puntero al objeto puede mantenerse en 16 bits

• __far: un puntero al objeto puede mantenerse en 24 bits

Un programa que use estas palabras clave adicionales cumplirá con esta regla siempre que el
compilador

admite esas palabras clave como una extensión de idioma.

 Regla 1.2 (Informativa): No se deben usar extensiones de idioma

Un programa que se basa en extensiones de lenguaje puede ser menos portátil que uno que no lo
hace. A pesar de que

El Estándar requiere que una implementación conforme documente cualquier extensión que
proporcione

para el idioma, existe el riesgo de que esta documentación no proporcione una descripción
completa del

comportamiento en todas las circunstancias.

Si no se aplica esta regla, la decisión de usar cada extensión de idioma debe justificarse en el

documentación de diseño del proyecto.

Los métodos por los cuales se garantizará el uso válido de cada extensión, también debe
documentarse.

Se reconoce que es necesario usar extensiones de lenguaje en sistemas embebidos. El estandar

requiere que una extensión no altere el comportamiento de ningún programa estrictamente

conforme.

Regla 1.3 (Necesaria): No habrá ocurrencia de comportamiento indefinido o crítico no especificado

Algunos comportamientos indefinidos y no especificados se tratan mediante reglas

específicas. Esta regla evita todo

otros comportamientos indefinidos y críticos no especificados. El Apéndice H enumera los

comportamientos indefinidos y los comportamientos no especificados que se consideran críticos,
junto con las pautas de MISRA C que evitan su ocurrencia.

Cualquier programa que dé lugar a un comportamiento indefinido o no especificado puede no

comportarse de la manera esperada. En muchos casos, el efecto es hacer que el programa no sea
portátil, pero también es posible que ocurran problemas más serios. Por ejemplo, el
comportamiento indefinido puede afectar el resultado de un cálculo.

El problema es particularmente difícil de detectar si el comportamiento indefinido solo se

manifiesta en raras ocasiones.

Nota: algunas implementaciones pueden proporcionar un comportamiento bien definido para

algunos de los comportamientos indefinidos y no especificados que se enumeran en The Standard.
Si se confía en tales comportamientos bien definidos, incluso mediante una extensión del
lenguaje, será necesario desviar esta regla con respecto a esos comportamientos.

2. CÓDIGO NO UTILIZADO

Regla 2.1 (Necesaria): Un proyecto no debe contener código inalcanzable

es una parte del código del programa que nunca se accede por construcciones de
programación.
Siempre que un programa no muestre ningún comportamiento indefinido, el código inalcanzable
no puede ser

ejecutado y no puede tener ningún efecto en los resultados del programa. La presencia de código
inalcanzable

por lo tanto, puede indicar un error en la lógica del programa.

Se permite que un compilador elimine cualquier código inalcanzable aunque no tiene que hacerlo.
Inalcanzable

el código que no es eliminado por el compilador desperdicia recursos, por ejemplo:

• Ocupa espacio en la memoria de la máquina de destino;

• Su presencia puede hacer que un compilador seleccione instrucciones de salto más largas y
lentas al transferir

control alrededor del código inalcanzable;

• Dentro de un ciclo, puede evitar que todo el ciclo resida en una memoria caché de instrucciones.

Si un compilador puede probar que una cláusula predeterminada es inalcanzable, puede

eliminarla, eliminando así la

acción defensiva

Regla 2.2 (Necesaria): No habrá código muerto

Cualquier operación que se ejecute pero cuya eliminación no afecte el comportamiento del
programa constituye

código muerto .

Dado que el código muerto puede

ser eliminado por un compilador, su presencia puede causar confusión.

Regla 2.3 (Informativa): Un proyecto no debe contener declaraciones de tipo no utilizadas

Si se declara un tipo pero no se usa, entonces no está claro para el revisor si el tipo es redundante o si ha sido
dejado sin usar por error

Regla 2.4 (Informativa): Un proyecto no debe contener declaraciones de etiquetas no utilizadas

Si una etiqueta se declara pero no se usa, entonces no está claro para el revisor si la etiqueta es redundante o si
ha sido
dejado sin usar por error.
Regla 2.5 (informativo): Un proyecto no debe contener declaraciones macro no utilizadas
Si se declara una macro pero no se usa, entonces no está claro para el revisor si la macro es redundante o si
se ha dejado sin usar por error

regla 2.6 (informativo): Una función no debe contener declaraciones de etiqueta no utilizadas
Si se declara una etiqueta pero no se usa, entonces no está claro para el revisor si la etiqueta es redundante o si
tiene
se ha dejado sin usar por error.

regla 2.7 (informativo): No debe haber parámetros no utilizados en las funciones.

La mayoría de las funciones se especificarán como el uso de cada uno de sus parámetros. Si un parámetro de
función no se utiliza,
Es posible que la implementación de la función no coincida con su especificación. Esta regla
destaca tales posibles desajustes

3. COMENTARIOS

Regla 3.1 (informativo): Las secuencias de caracteres / * and // no se utilizarán dentro de un

comentario

Si se produce un comentario que comienza la secuencia, / * o //, dentro de un comentario / *, es muy probable
que sea causado
por una secuencia de finalización de comentario / * faltante.
Si se produce una secuencia de inicio de comentario dentro de un // comentario, probablemente se deba a una
región de código
ha sido comentado usando //
Si se usa /* al final tiene que haber otro así */

Regla 3.2 (informativa): El empalme de línea no se utilizará en // comentarios

El empalme de línea ocurre cuando el carácter \ es seguido inmediatamente por un carácter de nueva línea. Si
el
el archivo fuente contiene caracteres multibyte, se convierten al juego de caracteres fuente antes de cualquier
se produce el empalme

Si la línea de origen que contiene un // comentario termina con un carácter \ en el conjunto de caracteres de
origen, el
La siguiente línea se convierte en parte del comentario. Esto puede provocar la eliminación involuntaria del
código

Para hacer conexión entre comentar una línea y otra.

https://www.tutorialspoint.com/es/compiler_design/compiler_design_code_generation.htm