Aquí podría ser tu PUBLICIDAD


¿Las herramientas de análisis de código estático de C ++ valen la pena?

votos
29

Nuestra gerencia ha estado hablando recientemente con algunas personas que venden herramientas de análisis estático C ++ . Por supuesto, los vendedores dicen que encontrarán toneladas de errores, pero soy escéptico.

¿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?

Publicado el 12/03/2009 a las 18:38
fuente por usuario David Norman
En otros idiomas...        العربية       

14 respuestas

votos
28

El análisis de código estático casi siempre vale la pena. 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 Lint no van a ayudar a una base de código pobre, pero una vez que tienes una buena base de código, puede ayudarte a mantenerla en buen estado.

Editar:

En el caso del producto de advertencia de más de 100.000, se dividió en aproximadamente 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 compilarlo primero :-)

Respondida el 12/03/2009 a las 07:19
fuente por usuario TofuBeer


Aquí podría ser tu PUBLICIDAD


votos
10

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.

Primero, 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 necesite 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, los comentarios sobre comentarios que se quejan de que los errores obviamente destructivos son "menores".

Mi consejo más importante es un corolario de mi primera ley, arriba: primero toma las fotos baratas 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 realmente flagrantes pueden ser políticamente útiles, por ejemplo, con una lista de los diez mejores de los defectos más divertidos, que pueden concentrar las mentes maravillosamente, si se usan con cuidado.

Respondida el 30/03/2009 a las 08:29
fuente por usuario Flash Sheridan

votos
5

Como señala un par de personas, si ejecuta una herramienta de análisis estático con un calibre completo en la mayoría de las aplicaciones, obtendrá muchas advertencias, algunas de ellas pueden ser falsos positivos o pueden no 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 ayudarte ...

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) Trabajar para borrar completamente la base de código 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.

Respondida el 31/05/2009 a las 12:11
fuente por usuario Sean

votos
5

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).

Respondida el 12/03/2009 a las 06:45
fuente por usuario dirkgently

votos
4

Probablemente tenga que lidiar con una buena cantidad de falsos positivos, particularmente si su código base es grande.

La mayoría de las herramientas de análisis estático funcionan con el uso de "análisis intraprocedimiento", lo que significa que consideran cada procedimiento de forma aislada, en oposición al "análisis de todo el programa" que considera todo el programa.

Por lo general, utilizan 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 en realidad nunca ocurrirá en la práctica y, por lo tanto, a menudo puede generar resultados positivos falsos.

El análisis intra-procedimiento elimina esos problemas simplemente enfocándose 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 luego describen cosas como "este campo nunca es nulo", "este búfer de cadena está protegido por este valor entero", "este campo solo puede accederse mediante el hilo etiquetado como 'fondo'", etc.

La herramienta de análisis 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 debe suponer lo peor y, por lo tanto, informará una gran cantidad de errores que en realidad no son 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 valga la pena 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 error con el que se encuentre más frecuentemente.

Respondida el 12/03/2009 a las 07:36
fuente por usuario Scott Wisniewski

votos
4

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.

Respondida el 12/03/2009 a las 06:55
fuente por usuario duffymo

votos
4

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 jóvenes a aprender mucho, pero se pueden usar como un mecanismo para ayudar a ajustar el código.

Descubrí que un segundo grupo de ojos (escépticos, indagadores para detectar errores) y las pruebas unitarias suelen ser los lugares donde he visto que se producen más errores.

Respondida el 12/03/2009 a las 06:43
fuente por usuario itsmatt

votos
3

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 utilizado la cobertura antes.

Ahora, Coverity se implementa en mi compañía y, cuando alguna vez obtenemos TR de un cliente en una versión anterior del software, estamos corriendo en contra de ella para sacar a los candidatos potenciales a la falla antes de comenzar el análisis en un sistema de suscripción.

Respondida el 13/03/2009 a las 11:00
fuente por usuario Warrior

votos
2

Este resultado bastante sorprendente se realizó utilizando Elsa y Oink.

http://www.cs.berkeley.edu/~daw/papers/fmtstr-plas07.pdf

"El análisis a gran escala de formato de cadena vulnerabilidades en Debian Linux" por Karl Chen, David Wagner, Universidad de Berkeley, {Quarl, daw}@cs.berkeley.edu

Abstracto:

insectos formato de cadena son una vulnerabilidad de seguridad relativamente común, y pueden provocar la ejecución de código arbitrario. En colaboración con otros, hemos diseñado e implementado un sistema para eliminar las vulnerabilidades de cadena de formato de toda una distribución de Linux, utilizando la inferencia typequali fi cador, una técnica de análisis estático que puede hallar manchar violaciónes. Analizamos con éxito el 66% de los paquetes de código C / C ++ en la distribución Debian Linux 3.1. Nuestro sistema fi NDS 1.533 advertencias de formato de cadena de olor sexual. Estimamos que el 85% de estos son verdaderos positivos, es decir, los insectos reales; haciendo caso omiso de los duplicados de las bibliotecas, alrededor del 75% son errores reales. Sugerimos que existe la tecnología para hacer que las vulnerabilidades de cadena de formato extintos en un futuro próximo.

Categorías y descriptores de asunto D.4.6 [Sistemas operativos]: Seguridad y protección de software invasivo; Condiciones generales: la seguridad, idiomas; Palabras clave: la vulnerabilidad de cadena de formato, el análisis a gran escala, Typequali fi cador de inferencia

Respondida el 26/01/2012 a las 08:27
fuente por usuario Daniel

votos
2

Como con todo, la respuesta depende ... si usted es el único desarrollador que trabaja en una impresora bonita de patrón 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.

Recientemente escribí una diatriba general sobre esto: http://www.redlizards.com/blog/?p=29

Debería escribir la parte 2 tan pronto como el tiempo lo permita, pero en general hacer algunos cálculos aproximados para ver si vale la pena:

  • ¿Cuánto tiempo pasó en la depuración?
  • ¿Cuántos recursos están ligados?
  • ¿Qué porcentaje podría haber sido encontrado por análisis estático?
  • costos para la configuración de la herramienta?
  • ¿precio de compra?
  • ¿tranquilidad de espíritu? :-)

Mi toma personal también es:

  • obtener análisis estático a principios de

    • temprano en el proyecto
    • temprano en el ciclo de desarrollo
    • temprano como muy temprano (antes de la construcción nocturna y las pruebas posteriores)
  • proporcionar al desarrollador la capacidad de utilizar el análisis estático a sí mismo

    • A nadie le gusta que los ingenieros de prueba o alguna herramienta anónima le digan lo que hicieron mal ayer
    • menos depuración hace feliz a un desarrollador :-)
    • proporciona una buena forma de aprender sobre dificultades (sutiles) sin vergüenza
Respondida el 19/05/2009 a las 04:37
fuente por usuario Ralf Huuck

votos
2

Supongo que depende bastante de tu estilo de programación. Si está escribiendo principalmente código C (con la característica ocasional de C ++), entonces estas herramientas probablemente serán capaces de ayudar (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).

Respondida el 12/03/2009 a las 07:16
fuente por usuario cmeerw

votos
2

El pago de la mayoría de las herramientas de análisis estático probablemente no sea necesario cuando hay algunos gratuitos gratuitos 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 .

Respondida el 12/03/2009 a las 06:41
fuente por usuario John Feminella

votos
1

El análisis estático que encuentra errores reales lo vale independientemente de si es 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.

Respondida el 12/03/2009 a las 07:21
fuente por usuario MSN

votos
0

En un empleador anterior que teníamos Asegurar ++. Se ayudó a determinar el comportamiento aleatorio (uso de material no inicializado), que Valgrind no pudo encontrar. Pero lo más importante: helpd para eliminar errores que no eran conocidos como errores todavía.

Asegurar ++ es bueno, pero caro, es por eso que compramos sólo una licencia de usuario.

Respondida el 26/04/2011 a las 01:09
fuente por usuario LennyStackOverflow


Aquí podría ser tu PUBLICIDAD