One Day de PVS-Studio Soporte al usuario

Damos la bienvenida a cualquier chat sobre la calidad del código. Nuestros clientes, estudiantes y otros usuarios de todos los rincones de Internet nos escriben. Independientemente del país, zona horaria o idioma. Bueno, hablando lenguaje, no programando. Entre los lenguajes de programación, hasta ahora estamos interesados ​​en un conjunto limitado. En este momento, es C, C ++, C # y Java. Hay muchos beneficios de la comunicación. Implementamos algunas sugerencias de los usuarios de inmediato, porque son realmente útiles. A menudo, solo echamos una mano al proyecto de alguien explicando las advertencias del analizador, que terminan siendo errores. Esta nota es sobre tal caso.

Sobre el analizador

PVS-Studio es una herramienta diseñada para detectar errores y vulnerabilidades potenciales en el código fuente de los programas, escritos en C, C ++, C # y Java. Funciona en entornos Windows, Linux y macOS.

Hay tres formularios de comentarios para contactarnos:

1. Retroalimentación
2. Solicitud de prueba
3. Solicitud de precio

Jueves noche

Un usuario activo que probó el analizador en su código comenzó a enviar advertencias falsas. Antes de que pudiera responder, ya había 3 correos electrónicos. Era el final de la jornada laboral y estaba cansado (hablando de la cuestión de la fiabilidad de la revisión manual del código). Nuestro equipo se estaba preparando activamente para un lanzamiento forjado, que estaba a unos días de distancia.

Decidí responder el viernes o incluso durante la próxima semana:

Hola Constantine

Revisaremos sus advertencias. La semana que viene comentaré lugares sospechosos :-)

Esta nota trata sobre la efectividad del análisis de código estático. La revisión manual del código será inferior a la verificación automática en muchos casos, especialmente al final del día.

Con el permiso del usuario, le citaré nuestros correos:

Email 1

Advertencias falsas positivas de V712:

uint32_t StartUpCounter = 0, HSEStatus = 0; RCC->CR |= ((uint32_t)RCC_CR_HSEON); /* Wait till HSE is ready and if Time out is reached exit */ { HSEStatus = RCC->CR & RCC_CR_HSERDY; StartUpCounter++; } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT)); // V712... 

Email 2

V715 falso positivo para el mismo fragmento:

 { // V715 ... lpmode.cpp 356 HSEStatus = RCC->CR & RCC_CR_HSERDY; StartUpCounter++; } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT)); 

Correo electrónico 3

¡Santos gatos, un lugar tan embrujado! El analizador se queja del mismo fragmento (consulte el código de los correos electrónicos anteriores):

V560 Una parte de la expresión condicional siempre es verdadera: (StartUpCounter! = ((Uint16_t) 0x5000)). lpmode.cpp 356

V776 Bucle potencialmente infinito. La variable en la condición de salida de bucle 'HSEStatus == 0' no cambia su valor entre iteraciones. lpmode.cpp 356

Tal vez no consigo algo? Pero en la práctica todo funciona, y si el cuarzo no comienza, entonces salimos de este fragmento en el tiempo de espera ;-)

Correo electrónico 4 (respuesta)

Hola Constantine

Revisaremos sus advertencias. La semana que viene comentaré lugares sospechosos :-)

Correo electrónico 5

¡Maldita sea! Solo después de su correo electrónico, noté que se pierde la declaración "hacer" ... ¡Finalmente, todo encajó! Parece que perdí completamente la nitidez de mis ojos%)

do {...} while (...);

Conclusión

Como habrás notado, hubo 4 advertencias del analizador para el mismo fragmento, pero aún así tomó tiempo convencer al usuario de que había un error. En tal situación, la revisión manual ni siquiera tendría una oportunidad.

Una historia similar con final feliz: " Cómo PVS-Studio demostró ser más atento que tres programadores y medio "

Use analizadores estáticos en su proyecto. No reemplazan la revisión de código con colegas, pero agregan soporte al control de calidad del código.