Nuestra gerencia ha estado hablando recientemente con algunas personas que venden C++ static analysis tools. Por supuesto, los vendedores dicen que encontrarán toneladas de errores, pero soy escéptico.¿Las herramientas de análisis de código estático C++ valen la pena?
¿Cómo funcionan estas herramientas en el mundo real? ¿Encuentran errores reales? ¿Ayudan a los programadores más jóvenes a aprender?
¿Valen la pena el problema?
Pagar la mayoría de las herramientas de análisis estático probablemente no sea necesario cuando hay algunas gratuitas gratuitas de muy buena calidad (a menos que necesite alguna característica muy especial o específica proporcionada por una versión comercial). Por ejemplo, vea esta respuesta que di en otra pregunta sobre cppcheck.
Los he usado - PC-Lint, por ejemplo, y encontraron algunas cosas. Normalmente son configurables y puedes decirles 'deja de molestarme con xyz', si determinas que xyz realmente no es un problema.
No sé si ayudan a los programadores junior a aprender mucho, pero se pueden usar como un mecanismo para ayudar a ajustar el código.
He descubierto que un segundo grupo de pruebas (escepticas, de sondeo para detectar errores) y de unidades es generalmente donde he visto que se producen más errores.
Cuando utilicé PC-Lint en un proyecto de C++, activé las advertencias efectivas en C++/C++ más efectivas y volvería a leer la sección del libro cuando violo una de las reglas. Esto realmente me ayudó a entender estas reglas en un contexto del mundo real. Lo encontré muy beneficioso. – Trent
Ayuda. Sugeriría que tomes una versión de prueba y la ejecutes a través de una parte de tu base de código que crees que se descuida. Estas herramientas generan muchos falsos positivos. Una vez que haya navegado a través de estos, es probable que encuentre un desbordamiento del búfer o dos que pueden guardar una gran cantidad de dolor en un futuro próximo. Además, pruebe al menos dos/tres variedades (y también algunas de las cosas de OpenSource).
+1 por sugerir el uso de una versión de prueba. Iba a hacer eso yo mismo. –
Esas herramientas ayudan. lint ha sido una gran herramienta para los desarrolladores de C.
Pero una objeción que tengo es que son procesos por lotes que se ejecutan después de haber escrito una buena cantidad de código y generar potencialmente muchos mensajes.
Creo que un mejor enfoque es construir tal cosa en su IDE y hacer que señale el problema mientras lo está escribiendo para que pueda corregirlo de inmediato. No permita que esos problemas ingresen al código base en primer lugar.
Esa es la diferencia entre la herramienta de análisis estático FindBugs para Java y el Inspector de IntelliJ. Yo prefiero mucho a este último.
Hay un plugin de Eclipse para FindBugs. –
¿Tiene un ejemplo de una herramienta de análisis estático interactivo para C++? Nunca he visto uno, pero me gustaría ver uno. – Tom
Soy desarrollador en redlizards.com: creamos Goanna, una herramienta de análisis estático C/C++ que tiene diferentes versiones para ejecutar con una creación nocturna, así como también está integrado en un IDE (plugins VS y eclipse). Puede valer la pena mirar. –
Supongo que depende bastante de su estilo de programación. Si en su mayoría escribes código C (con la característica ocasional de C++), estas herramientas probablemente te ayudarán (por ejemplo, administración de memoria, desbordamientos de búfer, ...). Pero si está utilizando funciones C++ más sofisticadas, las herramientas pueden confundirse al intentar analizar su código fuente (o simplemente no encontrará muchos problemas porque las instalaciones de C++ suelen ser más seguras de usar).
Esto está en línea con mi experiencia. Cuando utilicé PC-Lint hace 3 o 4 años, era demasiado ruidoso, e incluso después de volver a marcarlo, se quejaba de demasiadas cosas que no eran problemas. –
Esto estaba en una base de código que usaba funciones C++ bastante avanzadas. –
El análisis de código estático casi siempre lo vale. El problema con una base de código existente es que probablemente informe demasiados errores para que sea útil de manera inmediata.
Una vez trabajé en un proyecto que tenía más de 100.000 advertencias del compilador ... no tiene sentido ejecutar herramientas de Lint en esa base de código.
Usar las herramientas de Lint "a la derecha" significa comprar en un proceso mejor (lo cual es algo bueno). Uno de los mejores trabajos que tuve fue trabajar en un laboratorio de investigación donde no se nos permitió verificar el código con advertencias.
Entonces, sí, las herramientas valen la pena ... a largo plazo. En el corto plazo, convierta sus advertencias de compilación al máximo y vea lo que informa. Si el código está "limpio", ahora es el momento de buscar herramientas de pelusa. Si el código tiene muchas advertencias ... priorícelas y corrígelas. Una vez que el código no tenga ninguna (o al menos muy pocas) advertencias, mira las herramientas de Lint.
Por lo tanto, las herramientas de pelusa no van a ayudar a una base de código pobre, pero una vez que tenga una buena base de código que puede ayudar a mantener buena.
Editar:
En el caso del producto de 100.000 advertencia, que se dividió en unos 60 proyectos de Visual Studio. Como se eliminaron todas las advertencias de cada proyecto, se modificó para que las advertencias fueran errores, lo que impidió agregar nuevas advertencias a los proyectos que se habían limpiado (o más bien, permitió que mi compañero de trabajo gritara con sinceridad a cualquier desarrollador que ingresó código sin compilar primero :-)
Recientemente estaba trabajando en un nuevo producto de hardware/software en mi empresa, tuve la suerte de convencer al tipo a cargo de cambiar algunas advertencias del compilador a errores.El cambio de advertencia a error obligó a todos a deshacerse de estas advertencias. –
Este cambio de banderas del compilador fue lo mejor que pude para cambiar nuestro "estilo de codificación" y "procesos" sin tener que enviar un mandato de correo electrónico a todos. –
Creo que uno de mis días más felices fue comprobar el cambio a 60 proyectos con/W4 en ellos :-) – TofuBeer
El análisis estático que encuentra errores reales vale la pena, independientemente de si se trata de C++ o no. Algunos tienden a ser bastante ruidosos, pero si pueden detectar errores sutiles como las comparaciones firmadas/no firmadas que causan optimizaciones que rompen el código o los accesos de matriz fuera de límites, definitivamente valen la pena.
usted está probablemente va a tener que lidiar con una buena cantidad de falsos positivos, sobre todo si su base de código es grande.
herramientas de análisis más estáticas funcionan usando el "análisis intra-procesal", lo que significa que ellos consideran cada procedimiento de forma aislada, en lugar de "un análisis completo del programa", que considera la totalidad del programa.
Suelen utilizar el análisis "dentro del procedimiento" porque el "análisis de todo el programa" tiene que considerar muchas rutas a través de un programa que nunca ocurrirá en la práctica, y por lo tanto a menudo puede generar resultados falsos positivos.
análisis Intra-procedimiento elimina esos problemas por sólo se centra en un solo procedimiento. Sin embargo, para poder trabajar, generalmente necesitan introducir un "lenguaje de anotación" que use para describir metadatos para argumentos de procedimiento, tipos de devolución y campos de objeto. Para C++, esas cosas generalmente se implementan a través de macros con las que se decora. Las anotaciones describen cosas como "este campo nunca es nulo", "este búfer de cadena está protegido por este valor entero", "este campo solo se puede acceder mediante el hilo etiquetado como 'fondo'", etc.
El análisis herramienta tomará las anotaciones que proporcione y verificará que el código que escribió en realidad se ajuste a las anotaciones. Por ejemplo, si potencialmente puede pasar un valor nulo a algo que está marcado como no nulo, marcará un error.
En ausencia de anotaciones, la herramienta tiene que asumir lo peor, y así reportarán una gran cantidad de errores que no son realmente errores.
Dado que parece que ya no está utilizando una herramienta de este tipo, debe suponer que tendrá que dedicar una cantidad considerable de tiempo a anotar su código para deshacerse de todos los falsos positivos que inicialmente se informarán. Primero ejecutaba la herramienta y contaba el número de errores. Eso debería darte una estimación del tiempo que necesitarás para adoptarlo en tu código base.
Ya sea que la herramienta valga o no, la herramienta depende de su organización. ¿Cuáles son los tipos de errores que más te muerden? ¿Son errores de desbordamiento del búfer? ¿Son nero-dereference o errores de fuga de memoria? ¿Están enhebrando problemas? ¿Son "oops que no consideramos ese escenario", o "no probamos una versión de Chineese de nuestro producto que se ejecuta en una versión lituana de Windows 98?".
Una vez que descubra cuáles son los problemas, entonces debe saber si vale la pena el esfuerzo.
La herramienta probablemente ayudará con desbordamiento de búfer, desreferencia nula y errores de fuga de memoria. Existe la posibilidad de que pueda ayudar con el roscado de errores si tiene soporte para el "coloreado de hilos", los "efectos" o el análisis de "permisos". Sin embargo, esos tipos de análisis son bastante vanguardistas y tienen GRANDES cargas de notación, por lo que tienen algún costo. La herramienta probablemente no ayudará con ningún otro tipo de errores.
Por lo tanto, realmente depende del tipo de software que escriba y del tipo de errores que encuentre con más frecuencia.
Una buena característica de C++ es que las funciones y plantillas en línea significan mucho de información está disponible en una sola TU. Por lo tanto, una buena herramienta de análisis estático puede realizar un análisis inter-procedimental para las funciones que son visibles en la TU. –
Mi punto principal es que estas herramientas tienen costos de adopción potencialmente altos, y solo atrapan una clase limitada de errores. Eso significa que no son soluciones "universales". Pueden ser cruciales para algunos proyectos y una pérdida de tiempo para otros. Su uso debe basarse en la necesidad individual. –
Creo que vale la pena el análisis de código estático, si está utilizando la herramienta correcta. Recientemente, probamos la herramienta Coverity (un poco costosa). Es increíble, trajo muchos defectos críticos, que no fueron detectados por pelusa o purificar.
También encontramos que, podríamos haber evitado el 35% de los defectos de campo del cliente, si hubiésemos usado coverity anteriormente.
Ahora, Coverity se implementa en mi compañía y cuando recibimos un cliente TR en una versión de software anterior, estamos corriendo en contra de ello para mostrar los posibles candidatos para la falla antes de comenzar el análisis en un sistema de sush.
En mi experiencia con un par de empleadores, Coverity Prevent para C/C++ valió la pena, encontrando algunos errores incluso en el código de buenos desarrolladores, y muchos errores en el peor código de desarrolladores. Otros ya han cubierto aspectos técnicos, así que me centraré en las dificultades políticas.
En primer lugar, los desarrolladores cuyo código necesita más análisis estático, son los menos propensos a usarlo voluntariamente. Por lo tanto, me temo que necesitarás un sólido respaldo administrativo, tanto en la práctica como en teoría; de lo contrario, podría terminar simplemente como un elemento de la lista de verificación, para producir métricas impresionantes sin que realmente se solucionen los errores. Cualquier herramienta de análisis estático va a producir falsos positivos; Probablemente va a necesitar dedicar a alguien para minimizar la molestia de ellos, por ejemplo, al probar defectos, priorizar las fichas y ajustar la configuración. (Una herramienta comercial debe ser extremadamente buena para que nunca muestre un falso positivo más de una vez, ya que solo puede valer la pena el precio). Incluso los defectos genuinos pueden generar molestia; mi consejo sobre esto es no preocuparse, por ejemplo, comentarios de check-in refunfuñando que obviamente los errores destructivos son "menores".
Mi mayor consejo es un corolario a mi primera ley, arriba: Primero tome los tiros baratos , y mira los errores dolorosamente obvios de tus peores desarrolladores. Algunos de estos podrían haber sido encontrados por las advertencias del compilador, pero muchos errores pueden pasar por esas grietas, por ejemplo, cuando son suprimidos por opciones de línea de comandos. Los errores completamente evidentes pueden ser políticamente útiles, por ejemplo, con una lista de los 10 mejores de los defectos más divertidos, que pueden concentrar las mentes maravillosamente, si se usan con cuidado.
Coverity solo realiza análisis de archivo por archivo, por lo que si desea analizar cómo interactúan las funciones entre los archivos de fuentes, debe contratar a varias personas * (ya que esas herramientas no pueden realizar un análisis completo del programa) *. – user2284570
Como todo depende de la respuesta ... si usted es el único desarrollador que trabaja en una impresora bonita de patrones de punto para su abuela, probablemente no quiera comprar ninguna herramienta de análisis estático. Si tiene un proyecto de tamaño medio para software que entrará en algo importante y, además, tiene un calendario apretado, es posible que desee invertir un poco ahora que le ahorrará mucho más más adelante.
Hace poco escribí una queja general sobre esto: http://www.redlizards.com/blog/?p=29
que debería escribir parte 2 tan pronto como el tiempo lo permite, pero en general realizar algunos cálculos aproximados si vale la pena por usted:
Mi opinión personal es también:
obtener análisis estático a principios de
proporcionan al desarrollador con la capacidad de utilizar el análisis estático mismo
Como comentó un par de personas, si se ejecuta una herramienta de análisis estático de paso total en la mayoría de las aplicaciones, se obtiene una gran cantidad de advertencias, algunos de ellos pueden ser falsos positivos o no puede conducir a un defecto explotable. Es esa experiencia la que lleva a la percepción de que este tipo de herramientas son ruidosas y quizás una pérdida de tiempo. Sin embargo, hay advertencias que resaltarán defectos reales y potencialmente peligrosos que pueden generar problemas de seguridad, confiabilidad o corrección y para muchos equipos, estos problemas son importantes para solucionar y es casi imposible descubrirlos mediante pruebas.
Dicho esto, las herramientas de análisis estático pueden ser de gran ayuda, pero aplicarlas a una base de código existente requiere una pequeña estrategia. Aquí hay un par de consejos que pueden ayudarle ...
1) No encienda todo a la vez, decida sobre un conjunto inicial de defectos, active esos análisis y fíjelos en su base de códigos.
2) Cuando aborde una clase de defectos, ayude a todo su equipo de desarrollo a comprender cuál es el defecto, por qué es importante y cómo codificar para defenderse contra ese defecto.
3) de trabajo para despejar por completo el código base de esa clase de defectos.
4) Una vez que se haya solucionado esta clase de problemas, introduzca un mecanismo para permanecer en ese estado de cero problemas. Afortunadamente, es mucho más fácil asegurarse de que no está reintroduciendo un error si se encuentra en una línea base sin errores.
En un antiguo empleador teníamos Asegura ++. Ayudó a identificar el comportamiento aleatorio (uso de elementos no inicializados) que Valgrind no pudo encontrar. Pero lo más importante: ayudó a eliminar errores que aún no se conocían como errores.
Insure ++ es bueno, pero caro, es por eso que compramos solo una licencia de usuario.
Este resultado bastante sorprendente se logró con Elsa y Oink.
http://www.cs.berkeley.edu/~daw/papers/fmtstr-plas07.pdf
"Gran Escala de Análisis de formato de cadena vulnerabilidades en Debian Linux" de Karl Chen, David Wagner, la Universidad de Berkeley, {Quarl, daw}@cs.berkeley.edu
Resumen:
Los errores de formato de cadena son una vulnerabilidad de seguridad relativamente común y pueden llevar a la ejecución de código arbitrario. En colaboración con otros, diseñamos e implementamos un sistema para eliminar las vulnerabilidades de las cadenas de formato de una distribución completa de Linux, utilizando la inferencia de tipo de letra equitativa, una técnica de análisis estático que puede encontrar violaciones de corrupción. Analizamos con éxito el 66% de los paquetes fuente C/C++ en la distribución Debian 3.1 Linux. Nuestro sistema encuentra 1.533 advertencias de contaminación de cadena de formato. Estimamos que el 85% de estos son verdaderos positivos, es decir, errores reales; ignorando los duplicados de las bibliotecas, aproximadamente el 75% son errores reales. Sugerimos que la tecnología exista para hacer que las vulnerabilidades de las cadenas de formato se extingan en el futuro cercano.
Categorías y descriptores de tema D.4.6 [Sistemas operativos]: Seguridad y protección: software invasivo; Términos Generales: Seguridad, Idiomas; Palabras clave: Formato vulnerabilidad de cadena, análisis a gran escala, Typequali inferencia fi cador
John Carmack escribió recientemente acerca de esto: http://altdevblogaday.com/2011/12/24/static-code-analysis/ –
John Carmack. Análisis de código estático. Nuevo enlace: http://www.viva64.com/en/a/0087/ –
@DavidNorman: Todos ellos solo realizan análisis de archivo por archivo, por lo que si desea analizar cómo interactúan las funciones entre los archivos de fuentes, necesita acero para contratar varias personas * (dado que esas herramientas no pueden realizar un análisis completo del programa) *. – user2284570