Errores comunes en C: los fallos de principiante y cómo corregirlos

Todo programador de C se topa con la misma lista corta de errores, normalmente en la primera semana y de vez en cuando una década después. Lo que hace que valga la pena catalogarlos es que la mayoría producen mensajes de error que no los describen o, peor aún, ningún mensaje.

Cada entrada de abajo es un síntoma, la causa detrás de él y la solución.

Punto y coma olvidado y la cascada

Síntoma: un muro de errores, todos reportados en líneas que se ven correctas.

program.c:6:5: error: expected ';' before 'printf'
program.c:7:5: error: expected declaration specifiers before 'return'

Causa: C termina las instrucciones con ;. Si olvidas uno, el compilador pega la línea siguiente a la actual y luego reporta la confusión en el punto donde el texto combinado deja de tener sentido, típicamente en la línea siguiente.

int main(void) {
    int x = 5      /* falta el punto y coma */
    printf("%d\n", x);
    return 0;
}

Solución: cuando aparece un montón de errores, corrige solo el primero y vuelve a compilar. Todo lo que viene después puede ser consecuencia. Y revisa siempre la línea anterior a la que nombra el compilador.

La misma cascada surge de una llave sin cerrar o de un comentario /* sin terminar, donde los errores pueden aterrizar decenas de líneas más allá.

#include <stdio.h>

int main(void) {
    int x = 5;
    printf("%d\n", x);
    return 0;
}

Una nota extra: no lleva punto y coma después del encabezado de un if, for o while, ni después de la llave de cierre de una definición de función. if (x > 0); compila bien y no hace nada: el ; es todo el cuerpo.

Asignación en lugar de comparación

Síntoma: una condición que siempre es verdadera, o una variable que cambia misteriosamente.

int x = 5;
if (x = 10) {                 /* asigna 10, luego evalua 10 -> verdadero */
    printf("x es diez\n");    /* siempre imprime; x ahora vale 10 */
}

Causa: = asigna, == compara. El valor de una asignación es el valor asignado, así que if (x = 10) evalúa 10, que es distinto de cero, que es verdadero. El compilador lo acepta porque a veces es lo que la gente quiere decir.

Solución: usa == en toda condición y activa -Wall para que el compilador avise:

warning: suggest parentheses around assignment used as truth value

#include <stdio.h>

int main(void) {
    int x = 5;

    if (x == 10) {
        printf("x es diez\n");
    } else {
        printf("x es %d, no diez\n", x);
    }
    return 0;
}

Si de verdad quieres una asignación dentro de una condición (algo común con while ((c = getchar()) != EOF)), los paréntesis extra lo dejan claro y silencian la advertencia.

Declaración implícita de una función

Síntoma:

warning: implicit declaration of function 'printf'
warning: implicit declaration of function 'malloc'

...seguido a veces de resultados extraños en tiempo de ejecución o de un error de enlazado.

Causa: el compilador encontró una llamada a una función de la que no tiene declaración. En los dialectos anteriores a C99 suponía que la función devolvía int y seguía adelante; en sistemas de 64 bits esa suposición trunca un puntero devuelto a 32 bits, que es la forma en que un <stdlib.h> faltante convierte a malloc en un fallo.

Solución: incluye la cabecera correcta.

Para tus propias funciones, esa misma advertencia significa que llamaste a una antes de definirla. Pon un prototipo arriba de main:

#include <stdio.h>

int triple(int n);      /* prototipo: declarada antes de usarse */

int main(void) {
    printf("%d\n", triple(7));
    return 0;
}

int triple(int n) {     /* definicion, despues de main */
    return n * 3;
}

scanf sin el &

Síntoma: el programa falla al leer la entrada, o no lee nada y deja la variable sin cambios.

int age;
scanf("%d", age);     /* falta & : pasa el valor, no la direccion */

Causa: scanf escribe dentro de tu variable, así que necesita la dirección de la variable. Pasar age entrega la basura que hubiera en ella y scanf la trata como un lugar donde escribir, lo que suele ser un segfault.

Solución: un & antes de la variable, para todos los tipos excepto un array, que ya es una dirección:

#include <stdio.h>

int main(void) {
    int    age = 0;
    double height = 0.0;
    char   name[50] = "";

    /* Leemos desde una cadena para que el ejemplo corra sin entrada */
    sscanf("30 1.82 Alex", "%d %lf %49s", &age, &height, name);
    /*                                    ^    ^        ^
       & para int, & para double, sin & para el array            */

    printf("%s tiene %d y mide %.2f m\n", name, age, height);
    return 0;
}

Dos trampas vecinas de la misma familia: usa %lf para un double en scanf (ahí %f significa float, y escribir los bytes de un float dentro de un double lo deja mal) y acota siempre un %s con un ancho, %49s para un búfer de 50 bytes, o una palabra larga lo desbordará.

Mejor todavía: lee una línea completa con fgets y analízala, lo cual no puede desbordar y no deja entrada suelta en el búfer. Hay más sobre ambos en scanf.

Comparar cadenas con ==

Síntoma: dos cadenas que claramente coinciden se comparan como distintas.

char a[] = "hola";
char b[] = "hola";

if (a == b) {              /* compara dos direcciones: falso */
    printf("iguales\n");
}

Causa: una cadena de C no es un valor, es un puntero al primer carácter. == compara los punteros. Dos arrays que contienen el mismo texto viven en direcciones distintas, así que la prueba es falsa. (Para confundir más, comparar dos literales idénticos a veces da verdadero, porque el compilador puede guardar una sola copia, lo que hace que el error sea intermitente).

Solución: strcmp, y recuerda que devuelve 0 cuando son iguales:

#include <stdio.h>
#include <string.h>

int main(void) {
    char a[] = "hola";
    char b[] = "hola";
    char c[] = "mundo";

    printf("a == b (punteros):  %s\n", (a == b) ? "verdadero" : "falso");
    printf("strcmp(a, b) == 0:  %s\n", (strcmp(a, b) == 0) ? "verdadero" : "falso");
    printf("strcmp(a, c) == 0:  %s\n", (strcmp(a, c) == 0) ? "verdadero" : "falso");

    if (strcmp(a, b) == 0) {
        printf("Las cadenas coinciden\n");
    }
    return 0;
}

La lectura invertida también engaña a mucha gente: if (strcmp(a, b)) es verdadero cuando las cadenas difieren, ya que un resultado distinto de cero significa "no son iguales". Escribe siempre el == 0 de forma explícita.

División entera

Síntoma: un promedio de 0, un porcentaje que siempre es 0 o 100, una razón que perdió su parte fraccionaria.

int correct = 7, total = 10;
double score = correct / total;      /* 0.0, no 0.7 */

Causa: ambos operandos son int, así que C hace división entera y trunca antes de que el resultado se asigne a un double. 7 / 10 es 0; convertir 0 a double es 0.0.

Solución: haz que uno de los operandos sea de punto flotante antes de la división:

#include <stdio.h>

int main(void) {
    int correct = 7, total = 10;

    printf("correct / total            = %.4f\n", (double)(correct / total));
    printf("(double)correct / total    = %.4f\n", (double)correct / total);
    printf("correct / (double)total    = %.4f\n", correct / (double)total);
    printf("correct * 100.0 / total    = %.1f%%\n", correct * 100.0 / total);
    return 0;
}

Convertir un operando promueve el otro automáticamente. Convertir el resultado llega demasiado tarde: el truncamiento ya ocurrió. Consulta conversión de tipos.

La misma trampa se esconde en expresiones como (a + b) / 2 para un punto medio y 1 / 2 * x, que siempre es 0 sin importar cuánto valga x.

return faltante o equivocado

Síntoma: una función devuelve un número incorrecto pero verosímil, distinto en cada ejecución o en cada compilación.

int add(int a, int b) {
    int sum = a + b;
    /* sin instruccion return */
}

Causa: llegar al final de una función que no es void sin retornar da un valor no especificado: en la práctica, lo que hubiera quedado en el registro de retorno. Es comportamiento indefinido si quien llama lo usa.

La forma más traicionera retorna en algunos caminos y en otros no:

int classify(int n) {
    if (n > 0) return 1;
    if (n < 0) return -1;
    /* con n == 0 se cae por el final */
}

Solución: retorna en todos los caminos y compila con -Wall: el mensaje de GCC "control reaches end of non-void function" detecta ambas versiones.

#include <stdio.h>

int classify(int n) {
    if (n > 0) {
        return 1;
    }
    if (n < 0) {
        return -1;
    }
    return 0;          /* el camino que faltaba */
}

int main(void) {
    printf("%d %d %d\n", classify(5), classify(-5), classify(0));
    return 0;
}

Variables sin inicializar

Síntoma: salida basura, o resultados que cambian entre ejecuciones y entre niveles de optimización.

int total;                       /* contiene lo que hubiera en la pila */
for (int i = 1; i <= 5; i++) {
    total += i;                  /* sumando sobre basura */
}
printf("%d\n", total);           /* algun numero enorme */

Causa: las variables locales no se ponen en cero. Una variable global o static se inicializa a cero automáticamente; una local empieza con los bytes que ya estuvieran en esa dirección de la pila.

Solución: inicializa en el punto de la declaración. No cuesta nada y elimina toda esta clase de error:

#include <stdio.h>

int main(void) {
    int total = 0;              /* inicializada */
    int values[5] = {0};        /* todos los elementos en cero */
    char name[32] = "";         /* cadena vacia, no basura */

    for (int i = 1; i <= 5; i++) {
        total += i;
        values[i - 1] = i * i;
    }

    printf("total = %d\n", total);
    printf("values[4] = %d\n", values[4]);
    printf("name = '%s' (longitud %zu)\n", name, sizeof name);
    return 0;
}

-Wall -Wextra avisa de muchos de estos casos ("may be used uninitialized"), y -fsanitize=memory o valgrind atrapan el resto. Este es especialmente desagradable porque un puntero sin inicializar lleva directo a una falla de segmentación.

Desplazamiento por uno

Síntoma: se pierde el último elemento, o se toca un elemento de más y el programa se porta mal después.

int arr[5];
for (int i = 0; i <= 5; i++) {   /* toca arr[5], que no existe */
    arr[i] = i;
}

Causa: un array de n elementos tiene índices del 0 al n - 1. <= ejecuta una pasada de más.

Solución: el patrón i < n, y calcula n a partir del array en lugar de escribir el número dos veces:

#include <stdio.h>
#include <string.h>

int main(void) {
    int arr[5];
    size_t n = sizeof arr / sizeof arr[0];

    for (size_t i = 0; i < n; i++) {
        arr[i] = (int)i * 10;
    }
    for (size_t i = 0; i < n; i++) {
        printf("%d ", arr[i]);
    }
    printf("\n");

    /* Las cadenas necesitan un byte extra para el '\0' terminador */
    char word[6];                  /* 5 letras + terminador */
    strcpy(word, "hello");
    printf("'%s' usa %zu de %zu bytes\n", word, strlen(word) + 1, sizeof word);
    return 0;
}

La versión con cadenas (olvidar espacio para el '\0') es el mismo error con otro disfraz, y char word[5] con "hello" dentro es un desbordamiento de búfer.

Dos más pequeños que conviene conocer

Punto y coma después del encabezado de un bucle. for (int i = 0; i < 10; i++); seguido de un bloque entre llaves ejecuta el bucle diez veces sin hacer nada y luego ejecuta el bloque una vez. Compila sin quejarse.

sizeof sobre un puntero. Dentro de una función, un parámetro de tipo array es un puntero, así que sizeof(arr) es el tamaño del puntero (8 bytes), no el del array. Pasa la longitud como un argumento aparte:

#include <stdio.h>

void report(int arr[], size_t n) {
    printf("sizeof(arr) dentro de la funcion: %zu\n", sizeof arr);
    printf("cantidad real de elementos:       %zu\n", n);
}

int main(void) {
    int data[10] = {0};
    printf("sizeof(data) en main: %zu bytes\n", sizeof data);
    report(data, sizeof data / sizeof data[0]);
    return 0;
}

El hábito que previene casi todo esto

Compila con las advertencias activadas, desde el primerísimo programa:

gcc -Wall -Wextra -g program.c -o program

-Wall -Wextra detecta la asignación dentro de una condición, el return faltante, la lectura sin inicializar, la variable sin usar y el especificador de printf que no coincide con su argumento. Añadir -fsanitize=address,undefined durante el desarrollo atrapa casi todo lo demás en el momento en que ocurre.

Trata cada advertencia como un error con el que todavía no te has topado. Un programa en C que compila sin advertencias no tiene garantizada su corrección, pero casi todo programa en C que falla estaba advirtiendo algo antes.