Cómo detectar el comportamiento indefinido

Question

¿Hay alguna manera de saber si el programa tiene un comportamiento indefinido en C++ (o incluso C), salvo la memorización de toda la especificación?

La razón por la que pregunto es que he notado una gran cantidad de casos de programas working in debug but not release debido a un comportamiento indefinido. Sería bueno si hubiera una herramienta que al menos ayudara a detectar UB, entonces sabemos que existe la posibilidad de problemas.

Answer 1

Un buen compilador, como el compilador Intel C++, debería poder detectar el 99% de los casos de comportamiento indefinido. Tendrá que investigar las banderas y los interruptores para usar. Como siempre, lea el manual.

Answer 2

Bueno, this artículo cubre la mayoría de los aspectos ..

Answer 3

No estoy al tanto de cualquier herramienta de software para detectar todas las formas de UB. Obviamente, usar las advertencias de su compilador y posiblemente la pelusa u otro verificador de código estático puede ayudar mucho.

Otra cosa que ayuda mucho es simplemente la experiencia: cuanto más programes el lenguaje, más verás constructos que parecen sospechosos y podrás atraparlos antes en el proceso.

Answer 4

Creo que puede usar una herramienta de coverity para detectar errores que conducen a un comportamiento indefinido.

Supongo que podría usar theorem provers (solo conozco Coq) para asegurarse de que su programa hace lo que quiere.

Answer 5

herramientas de análisis de código estático como PC-Lint pueden ayudar mucho aquí

Answer 6

estándares de buena codificación. Protegerte de ti mismo Aquí están algunas ideas:

1. El código debe compilar en el nivel más alto de advertencia ... sin advertencias. (En otras palabras, su código no debe activar advertencias en absoluto cuando se establece en el nivel más alto.) Active el indicador de advertencia de error en todos los proyectos.

   Esto significa un trabajo extra cuando usa bibliotecas de otras personas ya que es posible que no lo hayan hecho. También encontrará que hay algunas advertencias que son inútiles ... desactívelas individualmente, como lo decida su equipo.

2. Siempre use RAII.

3. ¡Nunca use moldes de estilo C! ¡Nunca! - Creo que hay un par de casos raros en los que tienes que romper esto, pero probablemente nunca los encuentres.

4. Si debe reinterpret_cast o enviar a void, utilice una envoltura para asegurarse de que siempre está realizando el fundido en/del mismo tipo. En otras palabras, envuelva su puntero/objeto en un boost::any y coloque un puntero en lo que necesite y en el otro lado haga lo mismo. ¿Por qué? Porque siempre sabrá de qué tipo de reinterpret_cast y el boost::any hará cumplir que ha emitido el tipo correcto después de eso. Es lo más seguro que puedes obtener.

5. Siempreinicializar las variables en el punto de la declaración (o en inicializadores del constructor cuando en una clase).

Hay más, pero esas son algunas de las más importantes para empezar.

Nadie puede memorizar el estándar. Lo que hacemos los programadores de C++ intermedios a avanzados es utilizar construcciones que sabemos que son seguras y protegernos de nuestra naturaleza humana ... y no usamos construcciones que no son seguras a menos que tengamos que hacerlo y luego tenemos un cuidado especial para asegurarnos de que el peligro está envuelto en una agradable interfaz segura que se prueba al infierno y viceversa.

Una cosa importante recordar que es universal en todos los idiomas es:

hacer sus construcciones fácil de usar correctamente y difícil de usar de forma incorrecta

Answer 7

clang se esfuerza para producir advertencias cuando indefinido comportamiento se encuentra.

Answer 8

No es posible detectar un comportamiento indefinido en todos los casos. Por ejemplo, considere x = x++ + 1;. Si estás familiarizado con el idioma, sabes que es UB. Ahora, *p = (*p)++ + 1; es obviamente también UB, pero ¿qué pasa con *q = (*p)++ + 1;? Eso es UB si q == p, pero aparte de eso está definido (si se ve incómodo). En un programa dado, podría ser posible probar que p y q nunca serán iguales al llegar a esa línea, pero eso no se puede hacer en general.

Para ayudar a detectar UB, use todas las herramientas que tenga. Los buenos compiladores advertirán al menos los casos más obvios, aunque es posible que deba utilizar algunas opciones de compilación para obtener la mejor cobertura. Si tiene más herramientas de análisis estático, úselos.

Las revisiones de código también son muy buenas para detectar estos problemas. Úselos, si tiene más de un desarrollador disponible.

Answer 9

Simple: No haga cosas que no sabe que puede hacer.

• Cuando se está seguro o tiene la sensación de pescado, comprobar la referencia

Answer 10

Desafortunadamente, no hay manera de manera de detectar todos UB. Tendría que resolver el problema de detención para hacer eso.

Lo mejor que puede hacer es saber que muchas de las reglas como sea posible, mirar hacia arriba cuando está en duda, y consultar con otros programadores (a través de la programación en parejas, las revisiones de código o pregunta sólo SO)

La compilación con tantas advertencias como sea posible y bajo múltiples compiladores puede ayudar. Y ejecutar el código a través de herramientas de análisis estáticas como Valgrind puede detectar muchos problemas.

Pero, en última instancia, ninguna herramienta puede detectarlo todo.

Un problema adicional es que muchos programas realmente tienen que confiar en UB. Algunas API lo requieren, y solo asumen que "funciona en todos los compiladores".OpenGL lo hace en uno o dos casos. La API Win32 ni siquiera se compilará bajo un compilador compatible con los estándares.

Por lo tanto, incluso si tuviera una herramienta mágica de detección de UB, aún así se dispararía por los casos que no están bajo su control.