2012-01-20 10 views
20

¿Qué opciones de GCC se deben establecer para que GCC sea lo más estricto posible? (y quiero decir lo más estricto posible) Escribo en C89 y quiero que mi código sea compatible con ANSI/ISO.Opciones de GCC para el código C más estricto?

+0

Para más estricta que debe quedar claro qué norma que se dirigen. ANSI X3.159-1989 y/o ISO/IEC 9899: 1990, ISO/IEC 9899: 1999, o "C1X" del grupo de trabajo ISO/IEC (http://www.open-std.org/JTC1/SC22/ WG14) (JTC1/SC22/WG14). ANSI C y ISO C90 solo difieren en la numeración de la sección de la norma en sí AFAIK – mctylr

+0

@mctylr: "Estoy escribiendo en C89" parece perfectamente claro. –

+2

Estrictamente hablando, C89 no cumple con ANSI/ISO. El estándar ISO C actual es el publicado en 2011; ese es también el estándar ANSI C actual; los estándares de 1989, 1990 y 1999 son oficialmente obsoletos. Pero eso es solo una objeción a la redacción; todavía hay un amplio soporte para C89/C90 (más que para C99), y aún puede ajustarse a él incluso si ya no es un estándar oficial. –

Respuesta

18

le recomiendo usar:

-Wall -Wextra -std=c89 -pedantic -Wmissing-prototypes -Wstrict-prototypes \ 
    -Wold-style-definition 

Usted debe compilar con -O, así como -g como algunas advertencias sólo están disponibles cuando se utiliza el optimizador (en realidad, que suelen utilizar -O3 para detectar los problemas). Puede preferir -std=gnu89 ya que eso desactiva menos extensiones en las bibliotecas. OTOH, si está codificando el estricto ANSI C89, tal vez quiera deshabilitarlos. La opción -ansi es equivalente a -std=c89 pero no tan explícita o flexible.

Los prototipos faltantes le advierten sobre las funciones que se utilizan (o funciones externas definidas) sin un prototipo en el alcance. Los prototipos estrictos significa que no puede usar 'paréntesis vacíos' para declaraciones de funciones o definiciones (o punteros a funciones); necesita (void) o la lista de argumentos correcta. La definición de estilo antiguo descubre K & definiciones de funciones de estilo R, tales como:

int old_style(a, b) int a; double b; { ... } 

Si tiene suerte, usted no tendrá que preocuparse por eso. No tengo tanta suerte en el trabajo, y no puedo usar prototipos estrictos, para mi disgusto, porque hay demasiados indicadores de función descuidados.

Consulte también: What is the best command-line tool to clean up code

+1

Las opciones '-Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition' son una buena idea, pero no abordan la conformidad estándar. Las declaraciones y definiciones de funciones antiguas han quedado anticuadas desde 1989, pero aún son parte del lenguaje; incluso los compiladores conformes con C2011 deben soportarlos. –

+1

@Keith: tiene encendida la bandera '-pedantic' en su lectura: D Sí, pero aún así recomiendo usar las opciones para que el código sea transferible al máximo hacia versiones posteriores del estándar. No me sorprendería descubrir que C2021 finalmente pierde soporte estándar para las funciones que no son prototipos, aunque las implementaciones probablemente continuarán respaldando las notaciones antiguas durante otros 10-20 años después de eso. C11 también elimina 'gets()'; No espero que desaparezca de las bibliotecas durante mucho tiempo tampoco. Debería evitarse, aunque es totalmente compatible con C89. –

+0

Escribí una publicación sobre esto: http://shitalshah.com/p/how-to-enable-and-use-gcc-strict-mode-compilation/ – ShitalShah

6

Este conjunto de opciones es bastante bueno:

-Wall -Wextra -ansi -pedantic 

Vas a tener que leer la documentación para ver si hay algunas advertencias adicionales están quedando a cabo por esa combinación.

Debe advertirse que el estricto C89 no incluye compatibilidad con los comentarios del estilo //, y existen algunas restricciones bastante serias sobre la cantidad de caracteres significativos en los nombres de los objetos con enlaces externos.

+0

La documentación dice que "-ansi -pedantic" debería obtener un estricto ISO C90, y advertirá sobre CUALQUIER extensión GNU C (no solo aquellas que son incompatibles). Puede usar "-pedantic-errors" si quiere errores. Aunque no es realmente una cuestión de rigor, puedes considerar "-Werror", que convertirá las advertencias en errores. Aunque filosóficamente "Advertencias no son errores" –

Cuestiones relacionadas