Regla 0x8003h: Verificá con gcc, gdb y valgrind antes de entregar

0x8003h: Verificá con gcc, gdb y valgrind antes de entregar¶

Enunciado normativo¶

Antes de entregar, DEBE ejecutarse el programa bajo las tres herramientas básicas de verificación: compilación con advertencias (gcc -Wall -Wextra), depuración de fallos (gdb) y detección de errores de memoria (valgrind). NO DEBE entregarse código que no haya pasado por este tríptico.

¿Por qué existe esta regla?¶

El problema¶

Un programa puede producir la salida correcta y, aun así, leer memoria no inicializada, desbordar un arreglo o liberar dos veces el mismo bloque. Estos defectos no se ven a simple vista: se manifiestan como fallos intermitentes o como vulnerabilidades en otro contexto.

Las tres herramientas cubren tres clases distintas de defectos: el compilador detecta problemas de tipos y firmas; el depurador localiza el punto exacto de un fallo; el detector de memoria revela accesos y liberaciones incorrectas. Juntas son el estándar mínimo de verificación de la cátedra.

Consecuencias de violarla¶

Fundamento en la cátedra¶

Es la etapa de verificación del método. Se apoya en 0x5002h: Desarrollá y compilá siempre con todas las advertencias del compilador activadas (compilar con advertencias) y 0x6002h: Compilá con frecuencia y resolvé el primer error antes de continuar (ciclo corto de compilación). valgrind es obligatorio para todo programa con memoria dinámica.

Alcance y excepciones¶

Aplica a todos los trabajos prácticos. En programas sin memoria dinámica, valgrind se ejecuta igual para detectar accesos fuera de límites en la pila. Si el código usa assert, compilar también una versión sin -DNDEBUG para que las pruebas se ejecuten.

Ejemplos exhaustivos¶

❌ Contraejemplo 1 — Entregar “porque compila”¶

gcc main.c -o app && ./app
# Salida correcta con el ejemplo del enunciado -> se entrega

Por qué falla: la compilación sin advertencias no detecta el uso de memoria sin inicializar. El ejemplo del enunciado no ejercita el camino que falla.

❌ Contraejemplo 2 — Ignorar el core dumped¶

$ ./app
Segmentation fault (core dumped)

El estudiante modifica líneas al azar hasta que “deja de fallar”, sin saber cuál era la causa. Sin gdb no hay diagnóstico; el defecto suele reaparecer.

✅ Ejemplo conforme 1 — Tríptico completo¶

# 1. Compilacion estricta
gcc -Wall -Wextra -Werror -std=c11 -pedantic -g main.c -o app

# 2. Ejecucion bajo deteccion de memoria
valgrind --leak-check=full --error-exitcode=1 ./app

# 3. Ante un fallo, depuracion
gdb ./app
(gdb) run
(gdb) bt

Cada herramienta cubre un aspecto distinto y complementario.

✅ Ejemplo conforme 2 — Lectura de valgrind¶

==1234== Invalid write of size 4
==1234==    at 0x1092A3: cargar (main.c:42)
==1234==    by 0x1091F0: main (main.c:15)
==1234==  Address 0x... is 0 bytes after a block of size 40 alloc'd

El informe apunta a main.c:42: un acceso justo después del bloque. La corrección es un valor de índice, no “probar suerte”.

⚠️ Casos límite¶

• Programas interactivos: alimentar la entrada desde un archivo (./app < entrada.txt) para que valgrind sea reproducible.

• valgrind lento: es esperable; no es motivo para omitirlo.

• Sin errores no significa inmune: indica que los caminos ejecutados están limpios; hay que ejercitar todos los caminos.

• -g: compilar con información de depuración para que gdb y valgrind muestren líneas, no direcciones.

Cómo detectarla¶

Checklist de autocontrol¶

• ¿Compilé con -Wall -Wextra -Werror -Wpedantic y sin advertencias?

• ¿Ejecuté el programa bajo valgrind y no hay errores ni fugas?

• Ante un fallo, ¿usé gdb para localizar la línea en vez de adivinar?

• ¿Compilé con -g para obtener trazas legibles?

Reglas relacionadas¶

• 0x5002h: Desarrollá y compilá siempre con todas las advertencias del compilador activadas — advertencias del compilador.

• 0x6002h: Compilá con frecuencia y resolvé el primer error antes de continuar — compilación incremental.

• 0x7006h: Probá explícitamente los casos borde — casos borde que hay que ejercitar bajo el depurador.

• 0x8004h: Ejecutá la lista de verificación de calidad antes de entregar — lista de verificación de entrega.