c-programming/book/12-arenas.md

Capítulo 12 — Arenas (asignadores de región)

Capítulo avanzado. Se apoya en lo aprendido sobre punteros (08), struct (09) y memoria dinámica (09-memoria-dinamica). Leelo después de tener claros malloc, free y las operaciones con punteros.

---

12.1 El problema: malloc para todo, free para todo

Cuando recién empezás, la memoria dinámica parece simple:

Node *n = malloc(sizeof(Node));   // reservo
/* ... uso ... */
free(n);                          // libero

Ese par malloc/free funciona bien para un objeto. El problema aparece cuando tu programa necesita reservar muchísimas cosas pequeñas: nodos de un árbol, tokens de un parser, cadenas temporales, estructuras de un request HTTP, filas de una tabla, etc.

Ahí empezás a ver estos dolores:

• Seguís el rastro de cada free. Si te olvidás de uno, tenés una fuga de memoria (memory leak).
• Liberás dos veces lo mismo y el programa explota (double free).
• Usás memoria después de liberarla (use-after-free): el peor bug, porque a veces "funciona".
• Reservar mil veces un pedacito tiene costo: cada malloc lleva overhead interno.
• Manejar un error a mitad de camino (por ejemplo, falló el malloc número 400 de 1000) te obliga a liberar todo lo anterior. Código feo y frágil.

La pregunta clave es: ¿y si en lugar de reservar y liberar objeto por objeto, reservo un bloque grande y me olvido de liberar cada cosa individualmente?

---

12.2 ¿Qué es una arena?

Una arena (también llamada arena allocator, region allocator o bump allocator) es una estrategia de manejo de memoria donde:

1. Reservás un único bloque grande de memoria de una sola vez (por ejemplo, 1 MiB).
2. Repartís ese bloque de a poco, avanzando un cursor cada vez que alguien pide memoria.
3. No liberás objetos individuales. Liberás todo junto al final, de una sola vez.
4. Para "empezar de cero" sin devolverle la memoria al sistema, rebobinás el cursor al inicio.

La analogía más simple: pensá en una hoja de papel rayada.

• La hoja entera es el bloque que reservaste.
• El renglón donde vas escribiendo es el cursor/offset (offset).
• Cada vez que escribís algo, bajás al renglón siguiente: nunca reusás un renglón ya escrito.
• Cuando querés empezar de nuevo, raspás toda la hoja (reiniciás el cursor a 0). No vas borrando palabra por palabra.
• Al final, tirás la hoja a la basura (un solo free).

Esa es toda la idea. Un cursor que solo avanza. Por eso se le dice bump allocator: "bump" = golpear el cursor hacia adelante.

Ventajas

• Rapidísimo: asignar es sumar al offset. Sin listas internas, sin buscar huecos.
• Imposible olvidarse de un free individual: hay uno solo, el de la arena completa.
• Sin fragmentación visible: al liberar todo junto, no quedan "agujeros" sueltos.
• Manejo de errores simple: si algo falla a mitad de camino, tirás la arena entera.

Desventajas / cuándo NO usarla

• No podés liberar un objeto puntual. Si necesitás liberar una cosa y no todo, la arena no es la herramienta (o necesitás una arena con "checkpoints", ver 12.5).
• La memoria crece hasta el pico de uso. El offset solo sube; no se recupera hasta el reset.
• No sirve para estructuras de vida larga y tamaño impredecible que necesitan liberarse por partes (por ejemplo, una lista donde vas borrando el medio continuamente).

El caso de uso ideal

Cuando tenés muchos objetos pequeños con la misma vida útil y los liberás todos juntos:

• Parsear un documento: todos los tokens viven hasta que terminás de procesarlo.
• Procesar un request: toda la memoria temporal muere cuando respondés.
• Compilar / analizar texto: reservás muchísimo y tirás todo al final.
• Un juego: cada "nivel" o "frame" reserva y libera su propia arena.

---

12.3 Un primer ejemplo mínimo (comentado)

Este es material didáctico para entender el concepto. Los ejercicios del 12.8 te van a pedir que lo extiendas con features que acá no están. No es la solución de ningún ejercicio.

La estructura central tiene solo tres campos:

#include <stddef.h>   // size_t

typedef struct {
    unsigned char *buffer;  // el bloque grande (donde vive toda la memoria)
    size_t         capacity; // cuántos bytes entran en total
    size_t         offset;   // cuántos bytes ya se usaron (el cursor)
} Arena;

• buffer es el malloc grande. Es unsigned char * porque la arena es "bytes crudos": ella no sabe ni le importa qué tipo vas a guardar.
• capacity es el tamaño total. Sirve para saber cuándo no hay más lugar.
• offset es el cursor. Empieza en 0. Solo avanza.

¿Una arena guarda un solo tipo o varios? Una arena no tiene tipo: guarda bytes. El tipo no vive en la arena, sino en cómo vos interpretás el puntero que te devolvió arena_alloc. Por eso una misma arena puede contener, al mismo tiempo, tipos distintos —int, double, structs, cadenas—, cada uno en su propio hueco, siempre que respetes la alineación (ver 12.4.1). El ejemplo de la main en 12.3 ya lo hace: pide un Point y, del mismo bloque, un arreglo de 100 int. Lo único que la arena no hace es acordarse por vos a qué tipo corresponde cada puntero: eso queda de tu lado.

Crear y destruir la arena

#include <stdlib.h>  // malloc, free

// Reserva el bloque grande. Devuelve una Arena lista para usar.
Arena arena_create(size_t capacity) {
    Arena a;
    a.buffer   = (unsigned char *)malloc(capacity);
    a.capacity = capacity;
    a.offset   = 0;                      // cursor al principio
    return a;
}

// Libera TODO. Un solo free para toda la arena.
void arena_destroy(Arena *a) {
    free(a->buffer);      // chau bloque entero
    a->buffer   = NULL;
    a->capacity = 0;
    a->offset   = 0;
}

Fijate algo importante: arena_create devuelve una Arena por valor. La estructura es chica (3 campos), copiarla es barato, y así evitás que el llamador maneje memoria para la propia arena.

Repartir memoria: la única operación de asignación

// Pide `size` bytes a la arena. Devuelve un puntero a memoria SIN inicializar,
// o NULL si no queda espacio. NUNCA necesita saber cuándo liberar.
void *arena_alloc(Arena *a, size_t size) {
    // 1) Si la arena no queda con lugar suficiente, no hay nada que hacer.
    if (a->offset + size > a->capacity) {
        return NULL;  // "arena llena"
    }

    // 2) El punto de reparto es el cursor actual.
    void *ptr = a->buffer + a->offset;

    // 3) El cursor avanza. Esto es TODO lo que cuesta asignar: una suma.
    a->offset += size;

    return ptr;
}

Esa suma es el corazón de la arena. return a->buffer + a->offset; es literalmente "te doy el renglón donde está el cursor" y a->offset += size; es "bajo al renglón siguiente".

Mirá que nunca hay un free por objeto. No existe arena_free(ptr) porque no hace falta: cuando el llamador termine, llama a arena_reset o a arena_destroy.

Reservar es solo el primer paso. El puntero que devuelve arena_alloc es una dirección común y corriente: guardás y recuperás datos por él (*p = ..., x = *p), igual que con cualquier otro puntero. La arena no es una caja fuerte ni un tipo especial: es memoria normal que se libera en bloque. Por eso, en los ejercicios no alcanza con pedir bytes — hay que escribir en ese espacio y leerlo de vuelta para comprobar que sirve.

Reiniciar sin liberar: reaprovechar el bloque

// Vuelve el cursor a cero. La memoria NO se devuelve al sistema,
// pero podés volver a repartirla como si estuviera vacía.
void arena_reset(Arena *a) {
    a->offset = 0;
}

Esto es oro puro para bucles donde, en cada iteración, reservás un montón y al final ya no te importa: en vez de reservar y liberar 1000 veces, reseteás la arena y listo.

Cómo se usa todo junto (ejemplo de uso comentado)

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

typedef struct { int x, y; } Point;

int main(void) {
    // Una sola reserva grande para todo el programa.
    Arena arena = arena_create(1024 * 1024); // 1 MiB

    // Reservo un Point (nótese: uso sizeof del TIPO, no cuántos bytes "a mano").
    Point *p = (Point *)arena_alloc(&arena, sizeof(Point));
    p->x = 3;
    p->y = 4;

    // Reservo un arreglo de 100 enteros.
    int *numbers = (int *)arena_alloc(&arena, 100 * sizeof(int));
    for (int i = 0; i < 100; i++) {
        numbers[i] = i * i;
    }

    printf("p = (%d, %d), numbers[42] = %d\n", p->x, p->y, numbers[42]);

    // NADA de free(p), free(numbers): se liberan TODOS con la arena.
    arena_destroy(&arena);

    // Truco típico: reusar el mismo bloque en un bucle.
    // for (int frame = 0; frame < 60; frame++) {
    //     ... reservar todo lo del frame ...
    //     render();
    //     arena_reset(&arena);   // listo para el próximo frame, sin malloc/free
    // }
    return 0;
}

Ese es el mínimo viable. Con esto ya podés resolver cosas reales. Lo que sigue son los detalles que lo vuelven "de producción".

---

12.4 Dos detalles que sí importan

12.4.1 Alineación de memoria

Por qué a la CPU le importa dónde empieza un dato

Los procesadores no leen cualquier dirección igual de rápido, y algunos exigen que ciertos tipos empiecen en direcciones "redondas". Si repartís tamaños impares (3 bytes, 5, 1...) el próximo dato puede quedar desalineado y provocar lentitud o, en arquitecturas estrictas, un crash (comportamiento indefinido).

Pero antes de seguir hay que desarmar una trampa de vocabulario, porque es la raíz de tu duda:

"Múltiplo de su tamaño" es un atajo que solo vale para los primitivos. La regla de verdad es: cada tipo exige que su dirección sea múltiplo de su ALINEACIÓN, y la alineación no siempre coincide con el tamaño. Para int, double y char da igual; para un struct, casi nunca. Eso es exactamente lo que hace que te preguntes si podés mezclar tipos. Podés. Seguí leyendo.

La alineación es una propiedad del TIPO, no del dato ni de la arena

Una arena no tiene tipo: guarda bytes y no sabe qué vas a poner adentro. La alineación no es una propiedad del valor ni de la arena: es una propiedad del tipo que vos vas a escribir en ese hueco. El lenguaje ya sabe, para cada tipo, cuánto exige:

Tipo	Tamaño	Alineación típica (x86-64)
char	1	1
short	2	2
int	4	4
long, double, puntero	8	8
struct	según sus miembros (con relleno)	= la mayor alineación de sus miembros

La idea que te salva: UNA alineación para todos

Acá está la respuesta a tu primera pregunta. ¿Podés tener int, char, double y structs complejos en la misma arena, bien alineados? Sí, y no hace falta calcular nada por tipo.

La clave: si cada bloque arranca en un múltiplo de 8, entonces arranca también en un múltiplo de 4, de 2 y de 1. Un múltiplo de 8 es múltiplo de todos los divisores de 8. Así que alineando todo a 8 cubrís a la vez a char (1), int (4), double/puntero (8) y a cualquier struct cuya alineación sea ≤ 8:

base+0      base+8      base+16     base+24
  |           |           |           |
  v           v           v           v
[ double  ][ int     ][ char    ][ struct  ... ]
  ^8          ^8          ^8          ^8
  todos múltiplos de 8 -> 8, 4, 2 y 1 quedan satisfechos

Por eso el ejemplo de main en 12.3 puede pedir un Point y después 100 int del mismo bloque: no calculás la posición de nadie, alineás cada reparto al mismo valor y listo.

¿Qué alineación universal uso? 8 alcanza para int, double y punteros. Para estar cubierto ante cualquier tipo (incluido algún SIMD o long double), usá ARENA_ALIGN = _Alignof(max_align_t) (normalmente 16). Es el valor que el estándar considera suficiente para todo. Un poquito más de desperdicio, cero dolores de cabeza.

Structs: por qué el tamaño NO te dice la alineación

Esta es la parte que confunde. Mirá:

struct Mixed { char tag; int value; };   // sizeof = 8   | _Alignof = 4
struct Pair  { double a; double b; };    // sizeof = 16  | _Alignof = 8
struct Quad  { int a, b, c, d; };        // sizeof = 16  | _Alignof = 4

¿Por qué Mixed mide 8 y no 5? Porque el compilador inserta 3 bytes de relleno (padding) después de tag, para que el int caiga alineado a 4. Y mide 8 (múltiplo de 4) para que, en un arreglo Mixed items[10], el value del segundo elemento también quede alineado.

De ahí sale el dato que te ahorra todo el cálculo:

La alineación de un tipo SIEMPRE divide a su tamaño. Es una garantía del estándar de C, y existe precisamente para que los arreglos funcionen. Consecuencia directa: si alineás el bloque a la alineación del struct, todos sus miembros caen alineados solos. Nunca tenés que ubicar tag ni value a mano.

Entonces, tu pregunta "¿cómo calculo, en base al sizeof, la posición que debe ocupar un struct complejo?" tiene una respuesta incómoda y liberadora: no lo calcules desde el sizeof. El sizeof te dice cuánto ocupa, no dónde tiene que empezar. Para saber eso, pedile la alineación al lenguaje:

• _Alignof(Type) (C11) te da la alineación en bytes.
• alignof(Type) con <stdalign.h> (el alias con nombre lindo).
• _Alignas(16) en una variable te fuerza su alineación.

Cuidado con el sizeof como fuente de alineación. struct Pair (size 16) pide 8, no 16; struct Quad (size 16) pide 4, no 16. Si asumís "alineo a sizeof" vas a desperdiciar y, peor, a equivocarte con structs de tamaño impar (p. ej. size 24 con align 8). La alineación y el tamaño son primos hermanos, no gemelos.

Ejemplo paso a paso: alineación y tamaño de un struct

Vamos con un caso completo, miembro por miembro:

struct Record {
    int    a;   // 4 bytes
    int    b;   // 4 bytes
    double c;   // 8 bytes
    char   d;   // 1 byte
};

Paso 1 — la alineación de cada miembro. En x86/x64, lo habitual es:

Miembro	Tipo	_Alignof
a	int	4
b	int	4
c	double	8
d	char	1

Paso 2 — la alineación del struct. Es la regla del mayor: el alineamiento de una estructura es el mayor alineamiento de entre todos sus miembros.

max(4, 4, 8, 1) = 8

Por lo tanto _Alignof(struct Record) es 8.

Paso 3 — acomodar los miembros (y el relleno). El compilador ubica cada miembro en el primer offset que sea múltiplo de su alineación:

Miembro	Alineación	Offset donde cae	Ocupa
a	4	0	0..3
b	4	4	4..7
c	8	8	8..15
d	1	16	16
relleno final	—	17	17..23 (7 bytes)

Byte a byte queda así:

offset   0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16 |17 ... 23
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+----------+
       |     a (int)   |     b (int)   |           c (double)            | d | relleno |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+----------+
align    ^4              ^4              ^8                               ^1

• b termina en 8 y c pide 8: entra directo, sin relleno interno.
• d ocupa 1 byte (offset 16), pero el struct completo tiene que medir un múltiplo de 8.

Paso 4 — el sizeof. Contenido real: 4 + 4 + 8 + 1 = 17. Para que sea múltiplo de 8, se agregan 7 bytes de relleno al final:

sizeof(struct Record) = 17 + 7 = 24

La trampa del relleno final. El sizeof no es la suma de los miembros: incluye el relleno. Acá 4 + 4 + 8 + 1 = 17, pero sizeof es 24, no 16. Esos 7 bytes "fantasma" existen para que, en un arreglo struct Record items[7], cada elemento arranque alineado a 8. Si te olvidás del relleno final, el número no cierra.

_Alignof: ¿operador, macro o función?

_Alignof no es una función (no se llama en runtime, no existe un símbolo con ese nombre) y tampoco es, en sí mismo, una macro. Es un operador unario, igual que sizeof:

• Lleva el guión bajo (_Alignof) porque en C11 entró como palabra clave reservada: los identificadores con _ + mayúscula están reservados al lenguaje, así no choca con código viejo.
• Se evalúa en tiempo de compilación y produce un valor de tipo size_t (la cantidad de bytes de alineación).
• Su operando es un tipo entre paréntesis (_Alignof(double), _Alignof(struct Record)), no una variable.
• El _ inicial es feo a propósito. Por eso <stdalign.h> define el macro alignof, que se expande a _Alignof. Ahí está tu respuesta fina: alignof es un macro; _Alignof es la palabra clave. En C23 alignof pasó a ser palabra clave por derecho propio (y el macro se jubiló).

Cómo usarlo:

#include <stdio.h>
#include <stdalign.h>   // trae el macro `alignof`

typedef struct { int a; int b; double c; char d; } Record;

int main(void) {
    printf("sizeof(int)     = %zu\n", sizeof(int));       // 4
    printf("alignof(double) = %zu\n", alignof(double));   // 8
    printf("sizeof(Record)  = %zu\n", sizeof(Record));    // 24
    printf("alignof(Record) = %zu\n", alignof(Record));   // 8
    return 0;
}

Detalle de printf. _Alignof y sizeof devuelven size_t: imprimilos con %zu, no con %d (si no, el formato no coincide con el tipo y tenés undefined behavior).

Para la arena. Este es el número que le pasás a ARENA_ALIGN: _Alignof(max_align_t) cubre cualquier tipo; _Alignof(Record) alcanza para los Record. Lo importante: la alineación se lee del tipo, no se adivina desde el sizeof.

La fórmula, para tontos

El corazón de todo es redondear hacia arriba al múltiplo más cercano:

#define ARENA_ALIGN 8  // alineamos a 8 bytes (potencia de 2)

// Redondea n hacia arriba al múltiplo de ARENA_ALIGN más cercano.
#define ARENA_ALIGN_UP(n) (((n) + (ARENA_ALIGN - 1)) & ~(size_t)(ARENA_ALIGN - 1))

La parte & ~(ARENA_ALIGN - 1) parece magia negra, pero es solo aritmética de bits. Vamos despacio, con A = 8:

1. A - 1 = 7 = 0b0111. Es una máscara con los 3 bits de abajo en 1. Esos 3 bits son justo los que "sobran" dentro de un bloque de 8 (los números 0..7).
2. n + (A - 1) = n + 7. Sumar 7 "empuja" el número hacia arriba lo suficiente para que, cualquiera sea su resto dentro del bloque de 8, cruce al próximo límite. Si ya estaba justo en un límite, el +7 se queda adentro del mismo bloque y da lo mismo.
3. ~(A - 1) = ~0b0111 = 0b...11111000. El ~ invierte: ahora esos 3 bits bajos están en 0 y el resto en 1. Hacer & con esto borra el resto, deja los bits altos intactos.
4. Resultado: el mayor múltiplo de 8 que es ≤ n+7, o sea el menor múltiplo de 8 ≥ n.

Tabla, con bits de 4 para que se vea:

n	n + 7	n + 7 en binario	& ~7	resultado
0	7	0111	0000	0
1	8	1000	1000	8
7	14	1110	1000	8
8	15	1111	1000	8
9	16	1 0000	1 0000	16

Ahí está toda la fórmula: sumar A-1 y borrar los bits bajos con ~. Nada más.

¿Por qué solo sirve con potencias de 2? Porque ~(A-1) solo "borra exactamente los bits del resto" cuando A es potencia de 2. Para A = 10 esa máscara no existe y habría que dividir con / y %. Por suerte todas las alineaciones estándar son potencias de 2 (1, 2, 4, 8, 16...), así que el truco siempre aplica.

Aplicala a la posición, no al tamaño (variante robusta)

El capítulo redondea el tamaño y da por hecho que offset ya estaba alineado. Eso alcanza mientras el bloque base esté alineado y todos pidan lo mismo. La versión más honesta redondea el cursor antes de repartir, que es lo que de verdad querés: que el hueco nuevo empiece alineado.

void *arena_alloc(Arena *a, size_t size) {
    // Subo el cursor del offset al múltiplo de 8 más cercano ...
    size_t aligned = ARENA_ALIGN_UP(a->offset);
    // ... y recién ahí veo si entra el pedido exacto.
    if (aligned + size > a->capacity) {
        return NULL;
    }
    void *ptr = a->buffer + aligned;   // puntero al hueco ya alineado
    a->offset = aligned + size;        // el cursor queda donde termina el dato
    return ptr;
}

Diferencia con la versión anterior (la del capítulo, que redondea el tamaño): esta desperdicia menos (usa size exacto y solo paga el padding necesario antes del bloque) y expresa mejor la idea "alineá la dirección donde arranca el dato".

Ojo: el bloque base también manda

Todo lo anterior asume que a->buffer es múltiplo de 8. Como el puntero que devolvés es base + offset, si base está torcido, todo queda torcido y alinear el offset no sirve de nada.

• malloc garantiza la alineación de cualquier tipo, así que un bloque pedido con malloc es seguro.
• En cambio un unsigned char buffer[4096]; local puede quedar alineado a 1, ¡aunque el array sea grande! Si vas a prestar memoria (ejercicio 12.11), forzá la alineación o, mejor, alineá la dirección absoluta, que se banca hasta una base torcida:

#include <stdint.h>   // uintptr_t

void *arena_alloc(Arena *a, size_t size) {
    // Alineo la DIRECCIÓN real (base + offset), no solo el offset.
    uintptr_t start   = (uintptr_t)(a->buffer + a->offset);
    uintptr_t aligned = (start + (ARENA_ALIGN - 1)) & ~(uintptr_t)(ARENA_ALIGN - 1);
    size_t    pad     = aligned - start;   // los bytes que "sacrifico" para alinear

    if (a->offset + pad + size > a->capacity) {
        return NULL;
    }
    a->offset += pad + size;
    return (void *)aligned;
}

Ese pad = aligned - start es la respuesta literal a "cómo calculo la posición que debe ocupar": la posición es aligned, y el costo de alinear es pad. Simple y sin depender de que base haya venido alineado.

Lo que te llevás de alineación

• La alineación es del tipo, no del valor ni de la arena.
• Para mezclar tipos no calculás posiciones: elegís una alineación universal (_Alignof(max_align_t)) y alineás cada reparto. Un múltiplo de 8 ya es múltiplo de 8, 4, 2 y 1.
• La alineación de un struct = la mayor de sus miembros, y siempre divide a su sizeof. Si el bloque arranca alineado, los miembros caen alineados solos.
• La fórmula es (n + A - 1) & ~(A - 1), y solo funciona con A potencia de 2.
• El bloque base también tiene que estar alineado; lo más robusto es alinear la dirección absoluta, no solo el offset.

12.4.2 ¿Y si no entra lo que pedís?

En este ejemplo simple, arena_alloc devuelve NULL si la arena está llena. Un diseño más cómodo es que la arena sea una cadena de regiones (chunks): cuando una se llena, agrega otra y sigue. Eso permite "crecer" sin límite práctico, a costa de más código. Los ejercicios te van a pedir ambas variantes.

---

12.5 Conceptos que vas a necesitar después

• Checkpoint / restore (arenas temporales o scoped). Aunque la arena no libera objetos, podés guardar el offset actual (checkpoint), reservar cosas temporales, y luego volver a ese offset (restore) para descartar todo lo reservado desde el checkpoint. Es la forma de tener "sub-arenas" que se liberan parcialmente, sin un solo free.

• Helpers tipados. Escribir arena_alloc(&a, sizeof(Point)) es tedioso y propenso a error de tipo. Se acostumbra envolverlo en una función o macro que reciba el tipo: por ejemplo arena_alloc_type(&a, Point). Cuidado con las macros: el preprocesador juega sucio.

• Arena sobre memoria estática (stack/global). Si sabés que nunca necesitás más de X bytes, podés crear la arena sobre un unsigned char buffer[X]; local, sin malloc en absoluto. Rapidísimo y sin fugas. Limitación: no podés devolver punteros a esa memoria más allá de la función.

• Arena para cadenas. Como las cadenas son bytes, una operación muy útil es arena_strdup: copiar un const char * a la arena y devolver tu propia copia. Perfecto para tokens de un parser.

• Benchmark. Con frecuencia una arena es varias veces más rápida que miles de malloc. Medirlo es parte de entender el por qué.

---

12.6 Errores comunes (leelos, te van a pasar)

• Guardar punteros después de un reset/destroy y usarlos. Eso es use-after-free con otra cara. La arena te da velocidad, no inmunidad.
• Asumir que arena_alloc devuelve memoria en cero. malloc no limpia; la arena tampoco. Si necesitás ceros, acordate de inicializar (memset).
• Olvidar la alineación y sufrir undefined behavior con double/structs.
• Creer que podés liberar un objeto del medio. No se puede. Si lo necesitás, la estructura equivocada es la arena.
• Reservar la arena dentro de la función que la usa y devolverle un puntero a alguien. El bloque muere al salir de la función (si la creaste sobre el stack) o cuando la destruís.
• offset desbordado. Si no chequearas offset + size > capacity, escribirías fuera del bloque: buffer overflow clásico.

---

12.7 Dato de color: arenas en programas que probablemente uses

No es una curiosidad académica: este truco está metido en software masivo que usás todos los días. Cada caso nombra qué parte del programa la usa y para qué, como simple información (no hace falta entenderlos a fondo):

• Google Chrome, Microsoft Edge, Node.js (los tres corren el motor V8): V8 reserva los nodos del parser y del compilador de JavaScript en "zonas". La documentación lo dice tal cual: los bloques "no se pueden liberar por separado... se liberan todos juntos en una sola operación", y las zonas se usan "en todo el parser y los compiladores de V8". Terminado el script, la zona entera se tira de una sola vez.
• Mozilla Firefox (motor SpiderMonkey): usa un asignador llamado LifoAlloc, que su propia doc define como un bump allocator: "asignación rápida, pero incapaz de liberar asignaciones individuales". Se usa mientras se parsea y se compila (JIT) el JavaScript, y trae mark/release — el mismo checkpoint / restore del ejercicio 12.8.
• Juegos hechos con Unity (miles, y gran parte del mercado móvil): Unity documenta Allocator.Temp como un stack allocator del que "cada frame, el hilo principal crea un allocator Temp y lo libera por completo al final del frame". Es exactamente el arena_reset por frame del ejercicio 12.2, pero corriendo 60 veces por segundo.
• Python (CPython): el asignador de objetos chicos usa bloques llamados, literalmente, "arenas" (de 256 KiB). El archivo se llama, sin vueltas, Objects/obmalloc.c.
• Java y Android (y todo lo que corre encima, de apps móviles a Minecraft): la máquina virtual asigna objetos nuevos casi "empujando" un puntero en la generación joven (el famoso TLAB), sin buscar huecos. El aseo de la basura, otra vez, se hace en bloque.

De los que mencionaste —Word, Excel, Photoshop, Notepad, Paint— no tengo una fuente que afirme "acá usan una arena" y no te lo voy a inventar. Pero el concepto es el mismo: la próxima vez que leas "pool", "zone", "arena" o "region allocator" en el código de un programa grande, ya sabés de qué hablan.

---

12.8 Ejercicios

Dificultad incremental, de noob a pro. Cada ejercicio declara sus conceptos objetivo. Resolvelos usando esos conceptos. Sin código de solución: el libro te da el problema, no la respuesta.

Cada ejercicio trae un escenario de prueba: una secuencia concreta de operaciones y el resultado esperado. Usalo para probar lo que vas construyendo (imprimí el resultado real por consola y comparalo). El escenario describe entrada/salida esperada, nunca el algoritmo.

Ejercicio 12.1 — La arena mínima

Conceptos · struct, malloc, free, punteros, size_t

Contexto · Estás escribiendo la base de un asignador para un editor de texto que reserva muchos objetos pequeños de corta vida. Antes de optimizar nada, necesitás la estructura mínima de una arena. Simplificación: ignoramos alineación por ahora.

Consigna · Implementá una estructura Arena y las funciones arena_create, arena_alloc y arena_destroy. arena_alloc reparte el cursor y devuelve NULL si no hay lugar. Después de reservar, guardá un valor por el puntero (por ejemplo, un int) y leelo de vuelta: el espacio sirve solo si podés escribir y recuperar datos en él.

Entrada · Una capacidad en bytes y pedidos de tamaño variable. Salida · Punteros válidos dentro del bloque, o NULL cuando la arena se llena; y el valor guardado se recupera igual.

Escenario de prueba ·

capacity = 16

1. arena_create(16)  -> arena con 16 bytes disponibles
2. int *p = arena_alloc(4)  -> OK (base + 0)  ; *p = 7 ; leer *p -> 7
3. arena_alloc(4)    -> OK   (base + 4)
4. arena_alloc(8)    -> OK   (base + 8)   -> la arena queda llena
5. arena_alloc(1)    -> NULL ("no hay espacio")
6. arena_destroy()   -> el bloque completo se libera de una sola vez

(El reuso sin destroy se ve en el 12.2.)

Identificadores sugeridos · Arena, arena_create, arena_alloc, arena_destroy, capacity, offset

Criterios de aceptación ·

• arena_alloc devuelve direcciones contiguas y crecientes.
• Se guarda un valor por el puntero y se recupera intacto (el espacio es usable, no solo reservado).
• No se escribe nunca fuera del bloque.
• Un único free en arena_destroy libera todo.
• arena_alloc devuelve NULL exactamente cuando no hay lugar.

---

Ejercicio 12.2 — Reset y reutilización

Conceptos · punteros, ciclo de vida de memoria, for

Contexto · Un motor de juego reserva, en cada frame, un montón de datos temporales. Reservar y liberar 60 veces por segundo es un desperdicio. Simplificación: no hay gráficos, solo el ciclo de reservas.

Consigna · Agregá arena_reset que vuelva el cursor a 0 sin liberar el bloque. Simulá N "frames": en cada uno reservá varios objetos, escribí valores en ellos y leelos de vuelta, y recién después reseteá la arena. La dirección base del bloque no debe cambiar entre frames.

Entrada · Cantidad de frames y cuántos bytes reserva cada frame. Salida · Para cada frame, la dirección del primer objeto reservado (debe repetirse) y el uso total.

Escenario de prueba ·

capacity = 16 ; frames = 3 ; cada frame reserva 4 + 4 + 4 = 12

frame 0:
  int *a = alloc(4); *a = 10; leer *a -> 10   (offset 0)
  int *b = alloc(4); *b = 20; leer *b -> 20   (offset 4)
  reset -> offset vuelve a 0
frame 1:
  int *a = alloc(4) -> base + 0   (misma dirección que en el frame 0)
  *a = 30; leer *a -> 30          (el valor viejo ya no está: hueco reutilizado)
frame 2:
  int *a = alloc(4) -> base + 0   (otra vez la misma dirección)

Esperado: las tres primeras direcciones son idénticas y el programa hace un solo malloc en total.

Identificadores sugeridos · arena_reset, frame, frame_count

Restricciones / pistas · Después del reset, offset vuelve a 0 pero buffer es el mismo. Pensá qué pasa si guardás un puntero de un frame y lo usás en el siguiente.

Criterios de aceptación ·

• El bloque se reserva una sola vez.
• La primera dirección de cada frame es idéntica.
• Cada frame guarda y recupera sus valores correctamente del espacio reutilizado.
• No hay ningún malloc dentro del bucle de frames.

---

Ejercicio 12.3 — Alineación correcta

Conceptos · aritmética de bits, alineación, punteros

Contexto · Tu arena guarda mezclados char, int y double. Sin alineación, algunos accesos fallan en ciertas arquitecturas. Simplificación: solo verificamos direcciones múltiplo de la alineación.

Consigna · Modificá arena_alloc para que cada puntero devuelto quede alineado a un múltiplo de 8. Agregá una función arena_is_aligned que diga si una dirección dada es múltiplo de 8.

Entrada · Una secuencia de pedidos de tamaños impares (3, 5, 1, 9...). Salida · Las direcciones devueltas y un booleano de alineación para cada una.

Escenario de prueba ·

capacity = 32 ; alineación = 8

1. arena_alloc(3)  -> base + 0    (offset 0  -> 8)
   escribir 'A' en base + 0 y leer -> 'A'
2. arena_alloc(1)  -> base + 8    (offset 8  -> 16)
3. arena_alloc(5)  -> base + 16   (offset 16 -> 24)
4. arena_alloc(9)  -> NULL   (9 se redondea a 16 y solo quedan 8 bytes)
5. arena_alloc(8)  -> base + 24   (offset 24 -> 32; arena llena)
6. arena_alloc(1)  -> NULL

Además: arena_is_aligned(base + 0), + 8, + 16, + 24 -> todos true (múltiplo de 8).

Identificadores sugeridos · ARENA_ALIGN, arena_is_aligned, aligned

Restricciones / pistas · Redondeá el tamaño hacia arriba, no la dirección. Usá máscara de bits (asumiendo alineación potencia de 2).

Criterios de aceptación ·

• Toda dirección devuelta es múltiplo de 8.
• Reservar 1 byte consume 8 de capacidad.
• Se escribe y se lee un valor desde un hueco alineado.
• No se pierde memoria fuera de lo necesario (no redondeás de más).

---

Ejercicio 12.4 — Helper tipado

Conceptos · macros o funciones, sizeof, punteros genéricos (void *)

Contexto · Escribir arena_alloc(&a, sizeof(Point)) mil veces invita a errores de tipo. Querés una forma cómoda y segura de pedir "un objeto de tal tipo". Simplificación: solo tipos de tamaño fijo.

Consigna · Ofrecé una abstracción ARENA_ALLOC_TYPE(arena, Type) (o una función equivalente) que reserve exactamente sizeof(Type) bytes alineados y devuelva un puntero al tipo pedido, sin cast explícito en el sitio de uso.

Entrada · Distintos tipos (int, double, Point). Salida · Punteros usables directamente como el tipo pedido.

Escenario de prueba ·

capacity = 64 ; alineación = 8 ; Point = { int x; int y; } (8 bytes)

1. int    *n = ARENA_ALLOC_TYPE(&a, int);     -> OK (usa bytes 0..7)
2. double *d = ARENA_ALLOC_TYPE(&a, double);  -> OK (usa bytes 8..15)
3. Point  *p = ARENA_ALLOC_TYPE(&a, Point);   -> OK (usa bytes 16..23)
4. p->x = 3; p->y = 4; leer p->x / p->y       -> 3 y 4, sin `cast` en el llamador

Esperado: no aparece ningún (Point *) ni sizeof(Point) en el código que usa la macro.

Identificadores sugeridos · ARENA_ALLOC_TYPE, arena_alloc_type

Restricciones / pistas · Si usás macro, cuidá los paréntesis y evaluá el argumento una sola vez. Si usás void * + cast, explicá por qué el cast es seguro.

Criterios de aceptación ·

• El resultado se usa sin cast en el llamador.
• El tamaño reservado es exactamente sizeof(Type) (más alineación).
• Funciona con structs, no solo con tipos primitivos.

---

Ejercicio 12.5 — Una arena, muchos tipos

Conceptos · void *, cast, sizeof, alineación, punteros

Contexto · Un equipo de telemetría junta lecturas de sensores de distinto tipo —temperatura (double), cantidad de eventos (int), estado (char)— y, por velocidad, las guarda juntas en un único bloque temporal en lugar de reservar cada una por separado. Simplificación: no hay sensores reales, solo los valores mezclados.

Consigna · Usando una sola arena, reservá y guardá tres valores de tipos distintos (un double, un int, un char). Escribí cada valor, leelos de vuelta y comprobá que coinciden. Verificá además que cada puntero quede alineado a su tipo.

Entrada · Tres valores de tipos distintos. Salida · Los tres valores leídos correctamente desde la misma arena, y la comprobación de alineación.

Escenario de prueba ·

capacity = 64 ; alineación = 8

1. double *t = arena_alloc(&a, sizeof(double));  -> base + 0    (offset 0  -> 8)
2. int    *c = arena_alloc(&a, sizeof(int));     -> base + 8    (offset 8  -> 16)
3. char   *s = arena_alloc(&a, sizeof(char));    -> base + 16   (offset 16 -> 24)
4. *t = 36.5; *c = 42; *s = 'A';
   leer de vuelta  -> 36.5, 42, 'A'

Los tres punteros apuntan a huecos distintos del mismo bloque, y cada uno es múltiplo de 8.

Identificadores sugeridos · temperature, eventCount, status, arena_alloc

Restricciones / pistas · Un arena_alloc por valor, todos de la misma arena. No los envuelvas en un struct: la gracia es ver tipos sueltos conviviendo. Cuidá el cast al tipo correcto al leer.

Criterios de aceptación ·

• Los tres valores viven en una sola arena.
• Se leen de vuelta con el tipo correcto y coinciden con lo escrito.
• Cada puntero queda alineado a 8 (y por lo tanto a su tipo).
• Un único arena_destroy libera todo.

---

Ejercicio 12.6 — Arena para cadenas: arena_strdup

Conceptos · cadenas, strlen, memcpy, punteros, terminador '\0'

Contexto · Un tokenizador lee muchísimos const char * de un buffer grande y necesita copias propias que sobrevivan al buffer original. Simplificación: no implementás el tokenizador, solo la copia.

Consigna · Implementá arena_strdup(Arena *a, const char *src) que copie la cadena src (incluido el '\0') a la arena y devuelva el puntero a la copia. Si no hay lugar, NULL.

Entrada · Una o más cadenas de origen. Salida · Copias independientes cuyo contenido es igual al original.

Escenario de prueba ·

capacity = 16

1. arena_strdup(&a, "arena") -> OK  (6 bytes con terminador -> consumen 8)
2. arena_strdup(&a, "hola")  -> OK  (5 bytes con terminador -> consumen 8)
3. arena_strdup(&a, "x")     -> NULL (la arena está llena)
4. se modifica el original "arena" (por ejemplo, su primer byte)
   -> la copia sigue diciendo "arena"; strcmp(copia, "arena") == 0

Identificadores sugeridos · arena_strdup, src, dst

Restricciones / pistas · No olvides el byte del terminador: reservá strlen(src) + 1. No uses strdup de la librería: la gracia es hacerlo vos.

Criterios de aceptación ·

• La copia es válida aun si el src original se modifica o deja de existir.
• Se copia el terminador.
• Devuelve NULL si la arena no tiene lugar.

---

Ejercicio 12.7 — Estadísticas de uso

Conceptos · struct, punteros, aritmética, operadores relacionales

Contexto · En desarrollo querés detectar si tu arena de 1 MiB está siempre al borde del desborde, para dimensionarla bien. Simplificación: solo métricas, sin redimensionado.

Consigna · Agregá funciones que reporten: bytes usados, bytes libres, y el pico histórico de uso (el offset máximo alcanzado, aunque luego haya habido reset).

Entrada · Una secuencia de reservas y resets. Salida · used, remaining, peak correctos en cada momento.

Escenario de prueba ·

capacity = 64
operación          used   remaining   peak
-----------------  -----  ---------   ----
arena_create(64)     0        64         0
arena_alloc(8)       8        56         8
arena_alloc(16)     24        40        24
arena_reset()        0        64        24   <- peak NO baja
arena_alloc(4)       8        56        24
arena_alloc(40)     48        16        48
arena_reset()        0        64        48

Esperado: en toda fila used + remaining == 64, y peak solo puede subir.

Identificadores sugeridos · arena_used, arena_remaining, peak_usage

Restricciones / pistas · peak no puede bajar con reset: es un máximo histórico. Distinguí "usado ahora" de "usado alguna vez".

Criterios de aceptación ·

• used + remaining == capacity en todo momento.
• Tras varios resets con usos distintos, peak refleja el mayor uso jamás alcanzado.
• Ninguna función estadística reserva ni libera memoria.

---

Ejercicio 12.8 — Checkpoints (arenas temporales)

Conceptos · punteros, copia de estado, size_t, anidamiento lógico

Contexto · Dentro del procesamiento de un documento, cada sección necesita memoria temporal que podés tirar al terminar la sección, sin tirar lo acumulado antes. Simplificación: secciones anidadas de profundidad acotada.

Consigna · Implementá arena_checkpoint(Arena *a) que devuelva el offset actual, y arena_restore(Arena *a, size_t checkpoint) que vuelva el cursor a ese punto (descartando lo reservado después). Usalos para procesar secciones temporales anidadas.

Entrada · Una estructura de secciones que reservan y destruyen memoria temporal. Salida · Al restaurar, las reservas posteriores al checkpoint dejan de estar "vivas".

Escenario de prueba ·

capacity = 32

1. cp0 = arena_checkpoint(&a)   -> 0
2. int *x = arena_alloc(8); *x = 100; leer *x -> 100   (base + 0, offset 8)
3. arena_alloc(8)               -> base + 8     (offset 16)
4. cp1 = arena_checkpoint(&a)   -> 16
5. int *tmp = arena_alloc(8); *tmp = 999         (base + 16, offset 24)
6. arena_restore(&a, cp1)       -> offset 16    (se descarta `tmp`)
7. leer *x -> 100 (sobrevive al restore); usar `tmp` ahora es inválido
8. arena_alloc(16)              -> base + 16    (offset 32) -> reutiliza el hueco
9. arena_restore(&a, cp0)       -> offset 0     (se descarta todo)
10. arena_alloc(32)             -> base + 0     (offset 32) -> ahora sí entra

Ojo: el puntero devuelto en el paso 5 queda inválido después del paso 6.

Identificadores sugeridos · arena_checkpoint, arena_restore, checkpoint

Restricciones / pistas · Este es tu primer "liberar parcialmente" sin free. Cuidado: los punteros reservados después del checkpoint quedan inválidos al restaurar.

Criterios de aceptación ·

• Restaurar a un checkpoint rehabilita exactamente la capacidad liberada.
• Lo reservado antes del checkpoint conserva su valor tras restaurar.
• Checkpoints anidados funcionan (restaurar al más interno, luego al externo).
• Restaurar es O(1): solo escribe el offset.

---

Ejercicio 12.9 — Arena que crece (cadena de regiones)

Conceptos · malloc, free, structs enlazados, manejo de errores

Contexto · No sabés de antemano cuánta memoria necesita un request: a veces 4 KiB, a veces 50 MiB. Una arena de tamaño fijo te obliga a elegir mal. Simplificación: crecimiento por duplicación.

Consigna · Rediseñá la arena como una cadena de regiones (chunk): cuando una región se llena, se reserva otra (por ejemplo del doble de tamaño) y se sigue repartiendo ahí. arena_alloc nunca devuelve NULL salvo que la reserva del sistema falle.

Entrada · Una larga secuencia de reservas que superan con creces la capacidad inicial. Salida · Todas las reservas exitosas; los punteros viven hasta el arena_destroy.

Escenario de prueba ·

región inicial = 16 bytes ; crecimiento = x2 (la nueva región nunca es menor a lo pedido)

1. arena_alloc(12)  -> OK  (entra en la región 1; quedan pocos bytes)
2. arena_alloc(12)  -> OK  (no entra en la región 1 -> se crea la región 2, de 32)
3. arena_alloc(100) -> OK  (no entra en ninguna -> se crea la región 3, >= 100)
4. se leen los datos de los pasos 1 y 2 -> siguen intactos
5. arena_destroy()  -> se liberan las 3 regiones (cada una exactamente una vez)

Identificadores sugeridos · Chunk, arena_grow, next, chunk_size

Restricciones / pistas · Elegí una política de crecimiento y justificala. arena_destroy debe liberar todas las regiones, no solo la actual. Pensá el manejo de error si falla malloc.

Criterios de aceptación ·

• Pedir mucho más que la capacidad inicial no falla.
• arena_destroy libera cada región exactamente una vez.
• Los punteros ya entregados siguen válidos mientras la arena viva.
• El crecimiento no corrompe datos previos.

---

Ejercicio 12.10 — Arena como almacén de una colección

Conceptos · structs, arreglos dinámicos, punteros, arena_alloc

Contexto · Un sistema de contactos lee N registros de un archivo (nombre + teléfono) y los guarda en memoria temporal para procesarlos. Simplificación: lectura simulada, sin archivos reales todavía.

Consigna · Usando una arena (no un malloc por contacto), cargá una lista de contactos y luego calculá: cuántos hay, la longitud total de los nombres, y buscá un nombre. Liberá todo con un solo arena_destroy.

Entrada · N contactos con nombre (string) y teléfono. Salida · Cantidad, suma de longitudes, resultado de la búsqueda, y confirmación de que la memoria se libera de una sola vez.

Escenario de prueba ·

capacity = 4096
entrada:
  { "Ana",   "111" }
  { "Bruno", "222" }
  { "Carla", "333" }

salida esperada:
  cantidad                  = 3
  suma de letras de nombres = 3 + 5 + 5 = 13
  buscar "Bruno"            -> encontrado, teléfono 222
  buscar "Zoe"              -> no encontrado
  arena_destroy()           -> TODA la memoria se libera de una sola vez

Identificadores sugeridos · Contact, ContactList, contacts, load_contacts

Restricciones / pistas · Los nombres también van en la arena (arena_strdup). Si el arreglo de contactos puede crecer, decidí entre pedir capacidad fija o usar la arena que crece (12.9).

Criterios de aceptación ·

• Cero malloc/free por contacto: toda la memoria sale de la arena.
• Un único arena_destroy limpia todo.
• La búsqueda recorre correctamente los datos guardados en la arena.

---

Ejercicio 12.11 — Arena sin malloc (buffer estático)

Conceptos · arreglos locales, duración de almacenamiento, punteros, límites

Contexto · En un sistema embebido no querés tocar el heap: la fragmentación puede colgar el equipo. Reservás un buffer fijo en memoria y vivís con él. Simplificación: no hay embebido real, solo un buffer estático local.

Consigna · Creá una arena sobre un unsigned char buffer[4096]; local (sin malloc). Documentá con claridad por qué no podés devolver punteros a esa memoria desde la función que la crea, y demostralo con un caso que debe fallar (explicado en comentarios, sin ejecutarlo).

Entrada · Reservas de distinto tamaño dentro de la función. Salida · Direcciones dentro del rango [buffer, buffer + 4096).

Escenario de prueba ·

unsigned char buffer[4096];  (variable local) ; alineación = 8

1. arena_init_on(&a, buffer, 4096) -> arena sobre memoria prestada
2. char *s = arena_alloc(1000); copiar "hola arena" y leer -> "hola arena"
3. arena_alloc(3000) -> OK (offset 4000)
4. arena_alloc(96)   -> OK (llenó los 4096)
5. arena_alloc(1)    -> NULL
6. arena_destroy()   -> NO libera `buffer` (no es propia)

caso que DEBE fallar (explicado en comentarios, no ejecutado):
  una función crea la arena local y devuelve un puntero a un objeto de `buffer`;
  al volver, `buffer` ya no existe -> puntero colgante (dangling pointer).

Identificadores sugeridos · buffer, ARENA_STACK_SIZE, arena_init_on

Restricciones / pistas · La arena apunta al buffer, no lo posee: arena_destroy no debe hacer free. Refactorizá para que la arena funcione tanto con memoria propia como prestada.

Criterios de aceptación ·

• No se usa malloc en ningún lado.
• arena_destroy distingue "memoria propia" de "memoria prestada" y no libera la prestada.
• Se guarda y se lee una cadena desde el buffer prestado.
• Se explica y se evidencia el peligro de devolver punteros fuera de alcance.

---

Ejercicio 12.12 — Arena para un árbol sintáctico (pro)

Conceptos · structs con punteros, recursión, arena, cadenas, enum

Contexto · Escribir un mini-analizador de expresiones aritméticas (3 + 4 * (2 - 1)) donde cada nodo del árbol se reserva en una arena y todo se libera de golpe al terminar. Un caso clásico de "muchos nodos pequeños con la misma vida útil".

Consigna · Definí nodos (number, binop) e implementá el almacenamiento de nodos y de etiquetas de operador usando la arena. Recorré el árbol (recursivo) para imprimir la expresión en notación prefija y calculá el total de nodos y de bytes usados. Liberá con un solo arena_destroy.

Entrada · Tokens de una expresión (o la expresión ya tokenizada). Salida · La expresión en prefijo, el total de nodos y los bytes de arena consumidos.

Escenario de prueba ·

entrada (tokens): 3 + ( 4 - 1 )

salida esperada:
  prefijo: (+ 3 (- 4 1))
  nodos:   5
  bytes:   la suma de los sizeof reservados
           (por ejemplo, si sizeof(Node) == 16 -> 5 * 16 = 80)

Sin malloc por nodo; un único arena_destroy al terminar.

Identificadores sugeridos · Node, NodeKind, make_number, make_binop, print_prefix

Restricciones / pistas · Cada nodo y cada etiqueta salen de la arena, sin malloc. Pensá la vida útil: todos los nodos viven hasta terminar el análisis.

Criterios de aceptación ·

• Ningún nodo se reserva con malloc directo.
• El recorrido prefijo es correcto para expresiones anidadas.
• Un solo arena_destroy libera todo el árbol.
• Los conteos de nodos y bytes son exactos.

---

Ejercicio 12.13 — Arena vs malloc: medí y decidí (pro)

Conceptos · arena, malloc/free, medición de tiempo (clock), análisis de complejidad

Contexto · Tu equipo duda de si vale la pena migrar a arenas. Nada convence como un número. Simplificación: una medición simple en un solo proceso, sin herramientas externas.

Consigna · Implementá dos versiones del mismo workload (por ejemplo, crear y liberar 500.000 objetos pequeños): una con malloc/free por objeto y otra con una arena. Medí el tiempo de cada una con clock() y reportá ambas más la mejora destructiva (cuántas veces más rápida). Además, escribí un análisis (en comentarios o en el informe) de cuándo conviene cada enfoque, incluyendo un contraejemplo donde la arena pierde.

Entrada · Número de objetos y tamaño de cada uno. Salida · Tiempos de la versión con malloc y con arena, y la relación entre ellos.

Escenario de prueba ·

entrada: N = 500.000 objetos de 16 bytes cada uno

salida esperada (los tiempos son orientativos):
  malloc: 0.180 s
  arena:  0.021 s
  la arena es ~8.5x más rápida

contraejemplo (también forma parte del ejercicio):
  reservar 500.000 objetos y luego liberar la mitad "del medio" y seguir trabajando
  -> con malloc es natural; con una arena NO se puede -> la arena es la decisión equivocada

Identificadores sugeridos · bench_malloc, bench_arena, clock

Restricciones / pistas · El workload debe ser idéntico en ambas versiones para que la comparación valga. Cuidá que el compilador no optimice de más (los "objetos" deben tener efecto observable). El contraejemplo es obligatorio: medir no es lo mismo que entender.

Criterios de aceptación ·

• Ambas versiones hacen el mismo trabajo.
• La medición se repite y se reporta de forma honesta (sin descartar resultados incómodos).
• El análisis explica el resultado, no solo lo muestra.
• Se identifica al menos un escenario donde la arena es la decisión equivocada.

---

Ejercicio 12.14 — Registros heterogéneos con unión etiquetada (pro)

Conceptos · enum, union, punteros, arena, arreglo dinámico, switch

Contexto · Un sistema de auditoría registra eventos de distinto tipo —inicio de sesión (con usuario), compra (con monto) y error (con código)— en un mismo flujo temporal. Cada evento tiene una forma distinta, pero todos deben vivir juntos y liberarse de una sola vez. Simplificación: los eventos se generan a mano, sin persistencia.

Consigna · Definí un tipo Event con un enum kind y una union de cargas útiles (usuario como cadena, monto como double, código como int). Creá varios eventos de distinto tipo en una misma arena (las cadenas también salen de la arena), recorrelos y procesalos según su etiqueta (switch), e imprimí un resumen. Liberá todo con un solo arena_destroy.

Entrada · Una lista de eventos de tipos variados. Salida · Cada evento procesado según su tipo, un total de eventos y un conteo por tipo.

Ejemplo ·

entrada:
  LOGIN    usuario = "ana"
  PURCHASE monto   = 19.99
  ERROR    código  = 404

salida esperada:
  LOGIN ana
  PURCHASE 19.99
  ERROR 404
  total eventos = 3
  login = 1, purchase = 1, error = 1

Identificadores sugeridos · Event, EventKind, USER_MAX, make_login, make_purchase, make_error, process_events

Restricciones / pistas · La union ahorra memoria: todos los payloads comparten el mismo espacio y el enum te dice cuál es válido en cada momento. Reservá el evento y su cadena en la arena. Nunca leas el campo de la union que no corresponde al kind. Sin malloc por evento.

Criterios de aceptación ·

• Un solo arena_destroy libera los eventos y sus cadenas.
• El procesamiento respeta la etiqueta (switch sobre kind), sin leer campos inválidos.
• El conteo por tipo y el total de eventos son exactos.
• No hay malloc/free por evento.

---

12.9 Cierre

Una arena no es magia: es disciplina sobre la duración de los datos. Si entendés que un conjunto de objetos nace, vive y muere junto, ganás velocidad y simplicidad enormes. Si te olvidás de esa condición, la arena te muerde.

Regla mental para llevarte: una arena por "unidad de trabajo" (un request, un frame, un documento, un análisis). Cuando la unidad termina, la arena se resetea o se destruye. Nada más.