¿Es aconsejable usar Clang para el análisis de código personal en un proyecto que se construye con gcc?

Empecé a trabajar en varios proyectos de C que están construyendo usando gcc. Creo que esta elección se hizo por varias razones:

• Tuve que hacer una compilación cruzada para el brazo desde el principio (creo).
• El rendimiento es la primera y más importante especificación.
• gcc fue y sigue siendo la primera opción fácil.

No tengo ninguna razón para impugnar esa elección y no estoy en condiciones de hacerlo de todos modos.

La base de código de cualquier proyecto individual es relativamente pequeña. Cada proyecto se construye con un Makefile relativamente limpio (actualmente se está actualizando), gcc -Wall -Wextrano se queja en absoluto y se realizan algunas pruebas mínimas. No se realiza un análisis estático automatizado ni se formatea el código y el código no es sintácticamente consistente, aunque es muy legible y parece pensado.

No quiero volver a formatear cada línea de código a la vez, tengo la intención de hacer lo que se describe en alguna parte alrededor de esta respuesta (especialmente porque el contexto realmente no es tan malo): refactorizar y reformatear tanto como sea posible al tratar cualquier tema, pero sigue tomando temas sin intenciones de estilo de código en mente. Desafortunadamente, no estoy en condiciones de imponer un estilo de código o verificaciones adicionales en las confirmaciones, pero siento que hay una sensación entre mis colegas de que debe respetar la convención de código existente al modificar un archivo (aunque conozco el estado actual del código no ocurrió mágicamente), y un deseo de escribir un buen código.

Esta es la primera vez que programo en C con tal estado mental, y estoy muy atraído por las diversas herramientas de análisis y formato de código que clangofrece.

La esencia de mi pregunta es así: ¿podría generar problemas para seguir las clangsugerencias y utilizar clangherramientas de formato y análisis al construir con gcc? Por ejemplo, algunas advertencias podrían provenir de una representación interna gccque no se utiliza, o de un código de bytes clangque intentaría generar que gccno lo haga.

¿Hay una buena manera de pasar automáticamente los gccparámetros de compilación (principalmente la arquitectura de destino y el nivel de optimización) para clangque las sugerencias de advertencia tengan sentido?

Agregaré que estoy familiarizado gccy su informe de errores. Estoy interesado en obtener más advertencias y errores (relevantes), no solo mejor redactados y advertencias más comprensibles. Entonces, si no puedo confiar en las sugerencias adicionales que clangpueden producir en función de su representación interna porque construyo gccal final del día, entonces no estoy realmente interesado en hacerlo.

Incluí mucho contexto, así que siéntase libre de hacer cualquier comentario o responder cualquier pregunta subyacente que no pueda plantear.

Por ejemplo, algunas advertencias podrían provenir de una representación interna que gcc no usa, o de bytecode clang que intentaría generar que gcc no lo haga.

Extremadamente improbable. Clang te advierte sobre tu código, no sobre alguna representación interna que usa. Todas las advertencias deben derivar de algo sospechoso que está haciendo en su código, no de ningún detalle de implementación de clang.

Donde podría tener problemas es si alguno de los códigos que está utilizando utiliza C ++ no estándar. GCC admite muchas extensiones de C ++ que no serán aceptadas por otros compiladores. Si usa alguno de estos, es posible que clang simplemente se niegue a compilar su código. GCC debe admitir la compilación de una gran cantidad de código antiguo y (según tengo entendido) es más indulgente en algunos puntos que Clang.

Estoy usando ambos en el trabajo, gcc y clang. Obtendrá más advertencias con ambos compiladores juntos, por supuesto, y esto es genial. Por otro lado, las advertencias pueden contradecirse entre sí.

El caso más molesto que encontré es cuando clang detecta una defaultregla switchy dice que todos los valores ya están cubiertos y gcc insiste en tener un defaultcaso (documentado aquí ). Pero solo verá esta contradicción cuando configure advertencias muy estrictas en ambos compiladores.

Subjetivamente, diría que clang tiene advertencias más estrictas e incluso puede obtener más si usa -Weverythingo incluso el analizador de clang (analizador de código estático). Pero también he recibido advertencias que descubrió gcc y que también fueron importantes.

La mayoría de los conmutadores de compilador tienen exactamente el mismo nombre. Los nombres de los interruptores de advertencia difieren. Esto puede ser molesto si decide usar -Wno-*opciones para deshabilitar las advertencias. Por lo que puedo ver, no podrá evitar la compilación condicional en make / cmake, pero no es difícil resolver esto.

Evitaría formatear el código con herramientas automáticas. Es molesto porque contamina la salida de la culpa. Y luego las fusiones de larga duración pueden volverse muy difíciles.