El decaimiento a puntero

Escribes int v[10] y crees tener un objeto de diez enteros. Lo tienes, pero apenas dura: en cuanto ese nombre aparece en casi cualquier expresión, el compilador lo sustituye en silencio por la dirección de su primer elemento. El array no es un puntero —tienen tipos distintos, tamaños distintos y semánticas distintas—, pero se comporta como tal casi siempre. Esa asimetría entre lo que el tipo declara y lo que la expresión produce está detrás de la mitad de los malentendidos sobre C, y de una fracción nada despreciable de sus vulnerabilidades.

La regla exacta del decaimiento

El estándar lo dice con precisión quirúrgica: una expresión de tipo array de N elementos de T se convierte en una expresión de tipo puntero a T cuyo valor es la dirección del elemento cero. La conversión es implícita, ocurre en la evaluación de la expresión, y no modifica el objeto: el array sigue midiendo lo que medía en memoria.

int v[10];

int  *p     = v;    /* v decae: puntero al primer elemento, tipo int*      */
int (*fp)[10] = &v; /* &v NO decae: puntero al array entero, tipo int(*)[10] */

sizeof(v);          /* 40 con int de 4 bytes: el array completo */
sizeof(p);          /* 8: el tamano de un puntero, no del array  */

v + 1;              /* avanza 4 bytes: un int  */
&v + 1;             /* avanza 40 bytes: un array de 10 int */

v + 1 y &v + 1 apuntan a direcciones distintas aunque v y &v valgan lo mismo numéricamente. Ese es el resumen del tema en dos líneas: el valor coincide, el tipo no, y en C la aritmética la dicta el tipo.

Por eso v[i] es literalmente *(v + i): primero decae, luego suma escalada, luego desreferencia. El corchete no es un operador de arrays, es azúcar sintáctico sobre punteros. De ahí sale la curiosidad de que i[v] compile —la suma es conmutativa— y de ahí sale también algo mucho más importante: la indexación en C no sabe nada de arrays, así que no puede comprobar nada sobre ellos.

Los contextos que preservan el tipo

El decaimiento tiene excepciones, y son exactamente las situaciones en las que el compilador necesita el array entero, no su primer elemento.

Esa última distinción no es cosmética. char s[] = "hola" crea un array modificable de cinco bytes en el marco de pila; const char *p = "hola" te da un puntero a un objeto estático que casi con seguridad vive en una sección de solo lectura. Escribir en p[0] es comportamiento indefinido y en la práctica un fallo de segmentación.

El parámetro que miente

Aquí está la consecuencia que más daño hace. C permite escribir un parámetro con sintaxis de array, pero el estándar ajusta ese tipo a puntero antes de compilar nada:

void f(int arr[10]);   /* el compilador lo reescribe como int *arr */
void g(int arr[]);     /* identico al anterior */
void h(int *arr);      /* la misma funcion, sin disfraz */

Las tres declaran exactamente la misma función; puedes prototipar con una y definir con otra. El 10 de la primera es documentación para el lector humano y nada más: el compilador lo descarta y no comprueba que le pases diez elementos.

flowchart TD
A[Declaracion int v de 10 elementos] --> B[Objeto de 40 bytes con tipo completo]
B --> C[Aparece en una expresion]
C --> D[Decae a puntero al primer elemento]
D --> E[Se pierde la extension]
D --> F[Se pierde sizeof del array]
D --> G[Se pierde la comprobacion de limites del compilador]
E --> H[La funcion recibe solo una direccion]
F --> H
G --> H
H --> I[Hay que pasar la longitud por separado]
style I fill:#a6e3a1,color:#11111b

C23 ofrece una forma de recuperar algo de contrato: el calificador static dentro del índice del parámetro promete un mínimo de elementos.

/* Promesa: arr apunta a AL MENOS 4 enteros validos */
int suma4(int arr[static 4]) {
    return arr[0] + arr[1] + arr[2] + arr[3];
}

int par[2] = {1, 2};
suma4(par);   /* diagnostico en compiladores modernos */

No genera comprobación en tiempo de ejecución, pero habilita diagnósticos y permite al optimizador asumir que el puntero no es nulo. Es un contrato barato y expresivo, muy infrautilizado.

Reconstruir lo perdido

Tres estrategias, en orden creciente de rigor:

/* 1) La convencion universal: puntero mas longitud, siempre juntos */
size_t suma(const int *arr, size_t n);

/* 2) Puntero al array: el tipo lleva la extension consigo */
void procesa(int (*bloque)[64]);   /* exige exactamente 64 elementos */

/* 3) Envolver en struct: el array viaja por valor con su tamano */
struct buffer { size_t len; unsigned char datos[256]; };
void consume(struct buffer *b);    /* b->len siempre acompana a b->datos */

La opción 2 es la única en la que el compilador comprueba de verdad la extensión, y es la razón por la que las matrices bien tipadas del próximo capítulo son más seguras de lo que parecen. La opción 3 es la que usan los protocolos de red y los formatos binarios serios: el tamaño deja de ser un argumento que alguien puede olvidar y pasa a ser un campo que siempre está ahí.

Hay una cuarta vía moderna, incompleta pero útil: los atributos de la implementación. GCC y Clang entienden __attribute__((access(read_only, 1, 2))) para declarar que el primer parámetro es un buffer de solo lectura cuya longitud viene en el segundo, y _FORTIFY_SOURCE usa esa información para insertar comprobaciones cuando el tamaño es conocido en compilación. No es portable ni cubre todos los casos, pero convierte parte de la convención en algo que la herramienta puede verificar.

/* Un idioma util solo donde el array sigue siendo array */
#define ELEMENTOS(a) (sizeof (a) / sizeof (a)[0])

int v[10];
ELEMENTOS(v);      /* 10: correcto, v es un array en este ambito */

void f(int *p) {
    ELEMENTOS(p);  /* BASURA: sizeof(int*) / sizeof(int) */
}

Ese macro es correcto y es una trampa a la vez, porque su uso indebido no falla al compilar sino que produce un número pequeño y plausible. Por eso GCC ofrece -Wsizeof-pointer-div: la división de tamaños sobre un puntero es casi siempre este error.