malloc

Pourquoi réécrire malloc ?

Quand vous écrivez char *s = malloc(100); en C, vous utilisez sans y penser l'une des fonctions les plus complexes de la libc. Derrière cette apparente simplicité se cache un allocateur de mémoire qui doit : demander des pages au noyau via des syscalls coûteux, organiser ces pages en zones réutilisables, suivre quelles portions sont libres ou utilisées, fusionner les blocs libres adjacents pour éviter la fragmentation, gérer les accès concurrents depuis plusieurs threads, et tout cela en restant plus rapide qu'un accès tableau. La glibc consacre plus de 5000 lignes de C à cette tâche.

Le projet malloc de 42 vous demande d'écrire votre propre allocateur, à partir de zéro, en utilisant uniquement les syscalls mmap et munmap. L'objectif n'est pas de battre la glibc en performance — c'est de comprendre, de l'intérieur, comment fonctionne la mémoire dynamique. À la fin du projet, vous saurez exactement ce qui se passe quand vous écrivez malloc(42), du syscall noyau jusqu'au pointeur retourné.

Une brève histoire de l'allocation mémoire

Dans les années 1970, Unix gérait la mémoire heap via deux syscalls primitifs : brk et sbrk. Le heap était une région contiguë qui grandissait vers le haut — sbrk(n) étendait le heap de n bytes en déplaçant la "break point" du processus. Simple, mais avec deux défauts majeurs : impossible de rendre la mémoire au noyau au milieu du heap (seul le sommet pouvait être libéré), et totalement incompatible avec le multi-thread à cause de la contention sur le point de rupture global.

Dans les années 2000, Linux a introduit mmap qui permet de mapper n'importe quelle région de mémoire à n'importe quelle adresse, indépendamment du heap. Elle est devenue la primitive moderne pour l'allocation : chaque grosse allocation peut être sa propre région mmap, libérable individuellement par munmap. Le man de brk le dit lui-même : "historical curiosities left over from earlier days before the advent of virtual memory management". Le sujet 42 impose donc mmap — vous n'avez pas le droit d'utiliser brk/sbrk.

Avant d'écrire un allocateur, il faut comprendre comment Linux gère la mémoire. Sinon, vous écrirez du code sans savoir pourquoi il marche — ou pourquoi il plante. Cette section explique les concepts essentiels : pages virtuelles, page faults, coût des syscalls, et pourquoi mmap est la bonne primitive.

Pages virtuelles

Sous Linux x86-64, chaque processus a son propre espace d'adressage virtuel de 2^47 bytes (128 TB). Cet espace est découpé en pages de 4096 bytes (4 KB). Une page virtuelle peut être : (1) non mappée — n'existe pas, y accéder provoque un segfault ; (2) mappée mais pas chargée en RAM — y accéder provoque un page fault, le noyau charge la page depuis le swap ou l'initialise à zéro ; (3) mappée et en RAM — accès direct.

La traduction adresse virtuelle → adresse physique est faite par le MMU du CPU via une table des pages maintenue par le noyau. Cette traduction est mise en cache dans le TLB (Translation Lookaside Buffer) du CPU — un TLB miss coûte cher (plusieurs cycles pour parcourir les tables de pages). C'est pourquoi malloc essaie de garder les allocations proches en mémoire virtuelle : ça garde les entrées TLB chaudes.

mmap : la primitive moderne

mmap demande au noyau de mapper une région de mémoire virtuelle. Avec les flags MAP_ANONYMOUS | MAP_PRIVATE, on obtient une région anonyme (pas backing-file), privée (COW si on fork), initialisée à zéro (le noyau garantit que les pages anonymes sont zeroed au premier accès — sécurité). La signature :

void *mmap(void *addr, size_t length, int prot,
            int flags, int fd, off_t offset);

/* Pour notre malloc, on appelle toujours : */
mmap(NULL, length, PROT_READ | PROT_WRITE,
     MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

/* addr=NULL : laisse le noyau choisir l'adresse
   prot=RW : on veut lire et écrire
   flags=PRIVATE|ANONYMOUS : région privée sans fichier
   fd=-1, offset=0 : requis pour MAP_ANONYMOUS        */

mmap retourne l'adresse de la région, ou MAP_FAILED ((void*)-1) en cas d'erreur. La région est alignée sur une page : length est arrondi au multiple de 4096 supérieur. Pour libérer la région : munmap(ptr, length) — il faut connaître la taille exacte.

getpagesize() : la taille de page

getpagesize() retourne la taille d'une page mémoire — 4096 bytes sur Linux x86-64, mais potentiellement différent sur d'autres architectures (Mac ARM a des pages de 16384 bytes). Le sujet exige que les zones pré-allouées soient un multiple de getpagesize(), sinon le noyau gaspille de la mémoire en arrondissant lui-même. Notre Makefile lie getpagesize dynamiquement, et notre code l'appelle pour calculer la taille des zones LARGE.

$ getconf PAGESIZE
4096
$ cat /proc/cpuinfo | grep "model name" | head -1
model name      : Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz

Pourquoi pas brk/sbrk ?

L'ancien sujet malloc utilisait brk et sbrk, qui manipulent un pointeur de fin de heap unique par processus. Trois problèmes : (1) impossible de rendre de la mémoire au milieu du heap — seulement à la fin, ce qui empêche de libérer une grosse allocation tant qu'une petite existe après elle ; (2) pas thread-safe, le break point est global ; (3) limité à la taille du heap, alors que mmap peut mapper n'importe où dans l'espace virtuel. Le sujet moderne impose donc mmap, qui résout ces trois problèmes.

malloc est un projet central de la branche système de 42. Il s'agit d'écrire un allocateur de mémoire dynamique qui remplace celui de la libc, en utilisant uniquement les syscalls mmap et munmap pour interagir avec le noyau. La bibliothèque produite est une .so qui peut être préchargée via LD_PRELOAD pour remplacer transparentement le malloc système dans n'importe quel programme — y compris ls, cat, ou votre shell.

Sujet décortiqué

Le sujet officiel tient en quelques pages mais contient de nombreuses contraintes implicites. Décortiquons chaque exigence et son rationale.

Le nom de la bibliothèque

"The library must be named libft_malloc_$HOSTTYPE.so." — Pourquoi $HOSTTYPE ? Parce que la bibliothèque est compilée pour une architecture spécifique (x86_64, arm64, etc.) et que plusieurs versions peuvent coexister sur la même machine. Le Makefile doit détecter $HOSTTYPE (ou le calculer via $(shell uname -m)_$(shell uname -s) si vide, par exemple x86_64_Linux) et produire libft_malloc_$HOSTTYPE.so + un lien symbolique libft_malloc.so pointant vers elle.

Les trois catégories d'allocation

"TINY mallocs, from 1 to n bytes, will be stored in N bytes big zones. SMALL mallocs, from (n+1) to m bytes, will be stored in M bytes big zones. LARGE mallocs, from (m+1) bytes and more, will be stored out of zone." — Le sujet impose trois catégories mais laisse le choix de n, m, N, M. Notre choix : n=128, m=1024, N=16384 (4 pages), M=131072 (32 pages).

La règle des 100 allocations

"Each zone must contain at least 100 allocations." — Cette règle évite deux extrêmes : (1) des zones minuscules qui rappelleraient mmap à chaque allocation (lent), (2) des zones énormes qui gaspilleraient la mémoire si peu d'allocations sont faites. Avec notre choix : TINY peut contenir 102 blocs de 128B, SMALL peut en contenir 124. Les deux dépassent 100.

Le format de show_alloc_mem

Le sujet impose un format précis pour l'affichage, avec les adresses en hexadécimal, triées par ordre croissant (dans la pratique sur Linux, mmap retourne des adresses décroissantes, donc l'ordre d'insertion LIFO correspond à l'ordre croissant), et un total en bas. Le respect strict du format est noté — un format légèrement différent (par exemple lowercase vs uppercase, ou "TOTAL" au lieu de "Total") peut faire perdre des points.

Fonctions à implémenter

Fonctions autorisées

Les deux globales autorisées

"You are allowed a global variable to manage your allocations and one for the thread-safe." — La norme 42 interdit normalement les globales, mais le sujet malloc en autorise explicitement deux. Notre implémentation utilise une seule globale g_malloc de type t_malloc, qui contient les trois têtes de listes (TINY, SMALL, LARGE) et le mutex thread-safe. C'est plus propre que deux globales séparées — le mutex est physiquement adjacent aux données qu'il protège.

Bonus : quand les faire, dans quel ordre

Le sujet dit : "We will look at your bonuses if and only if your mandatory part is EXCELLENT." — Si le mandatory a un seul bug (crash sur un test, segfault sur une edge case), les bonus sont ignorés. Donc l'ordre de priorité est :

1. Mandatory complet et robuste — malloc/free/realloc/show_alloc_mem sans aucun crash sur tous les tests
2. Thread-safety — mutex dans malloc/free/realloc, test multi-thread
3. Défragmentation — merge_next/merge_prev dans free (déjà quasi-mandatory pour passer test2)
4. show_alloc_mem_ex — hex dump pour le debug
5. MALLOC_DEBUG — variables d'environnement
6. calloc — bonus simple (malloc + memset)

Notre implémentation couvre les 5 (sur 6 ideas listées par le sujet), dans cet ordre de priorité. La défragmentation est techniquement un bonus mais sans elle, le test2 (malloc + free) échoue — le sujet compte le nombre de page faults, et sans merge, chaque free laisse un bloc libre qui ne peut pas servir une allocation plus grande, donc mmap est rappelé.

Cette section présente les choix de design fondamentaux : les structures de données, le layout mémoire d'une zone, et l'organisation en 10 fichiers. Ces choix sont motivés par les contraintes du sujet (zones pré-allouées, 100 allocations minimum, norme 42) et par des considérations de performance (limiter les appels mmap).

Vue d'ensemble du design

Notre allocateur repose sur trois concepts : les zones (régions continues obtenues via mmap), les blocs (subdivisions d'une zone, marqués libres ou utilisés), et la globale g_malloc qui pointe vers la tête de chaque liste de zones (TINY, SMALL, LARGE). Le choix de la zone dépend de la taille demandée : ≤ 128 bytes → TINY, ≤ 1024 bytes → SMALL, au-delà → LARGE.

Structures de données

Trois structures composent l'allocateur, définies dans includes/malloc.h. Le choix de mettre les métadonnées avant le payload (plutôt que dans une table séparée) permet de retrouver le bloc à partir du pointeur utilisateur en soustrayant simplement sizeof(t_block) — un O(1) déterministe, sans lookup.

typedef struct s_block
{
 size_t                   size;       // taille du payload utilisateur
 int                              free;       // FREE=0 (libre) ou USED=1 (utilisé)
   struct s_block     *next;      // bloc suivant dans la zone
   struct s_block     *prev;      // bloc précédent dans la zone
}                               t_block;            // taille: 32 bytes (sur 64 bits)

typedef struct s_zone
{
 int                              type;       // TINY=0, SMALL=1, LARGE=2
 size_t                   size;       // taille totale de la zone (multipage)
struct s_zone *next;       // zone suivante du même type
t_block                   *blocks;     // pointeur vers le premier bloc
}                               t_zone;             // taille: 32 bytes

typedef struct s_malloc
{
 t_zone                   *tiny;       // tête de liste des zones TINY
 t_zone                   *small;      // tête de liste des zones SMALL
 t_zone                   *large;      // tête de liste des zones LARGE
 pthread_mutex_t  lock;       // mutex pour thread-safety
}                               t_malloc;           // la seule globale

extern t_malloc       g_malloc;

Pourquoi ces structures ?

t_block contient la taille du payload (pas la taille totale incluant header — important pour les calculs de split/merge), un flag free/used (un int plutôt qu'un bool pour l'alignement), et deux pointeurs next/prev. La liste doublement chaînée permet le merge dans les deux sens en O(1) — sans prev, il faudrait reparcourir la zone depuis le début pour trouver le bloc précédent, ce qui serait O(n).

t_zone contient le type (TINY/SMALL/LARGE — un int plutôt qu'un enum explicite pour rester compatible C89), la taille totale (nécessaire pour munmap qui exige la taille exacte), un pointeur next vers la zone suivante, et un pointeur vers le premier bloc. Pas de prev : on insère toujours en tête de liste, donc on n'a pas besoin de modifier le précédent.

t_malloc agrège les trois têtes de listes et le mutex. C'est la seule globale — initialisée statiquement avec PTHREAD_MUTEX_INITIALIZER pour éviter tout problème d'initialisation paresseuse en multi-thread.

Zones TINY / SMALL / LARGE — choix des tailles

Le sujet exige trois catégories d'allocations avec des tailles de zone pré-définies et un multiple de getpagesize() (4096 bytes sur Linux x86-64). Le choix de n (TINY_MAX) et m (SMALL_MAX) est libre. Nous avons choisi 128 et 1024 pour des raisons de simplicité et d'alignement avec les puissances de 2.

Les zones TINY et SMALL sont pré-allouées à la première demande et réutilisées pour les allocations suivantes de même catégorie. Une zone LARGE est créée à la demande pour chaque allocation, dimensionnée exactement à (size + headers) arrondi au multiple de getpagesize() supérieur, et libérée intégralement par munmap au moment du free.

Organisation en 10 fichiers

Pour respecter la norme 42 (5 fonctions max par fichier, 25 lignes max par fonction), le projet est découpé en 10 fichiers sources. Les fonctions helpers sont rendues non-static pour pouvoir être partagées entre fichiers via prototypes dans malloc.h. C'est un compromis : on perd l'encapsulation du static, mais on évite la duplication de code (qui violerait aussi la norme).

Arbre de dépendances des fichiers

La fonction malloc(size_t size) est le point d'entrée principal. Cette section décortique chaque étape : le dispatcheur, la recherche dans les zones existantes, la création de nouvelle zone, le split de bloc, et le cas spécial LARGE. On termine par une trace complète d'une séquence d'appels.

Le dispatcheur (fonction principale)

La fonction malloc elle-même est courte — c'est un dispatcheur qui choisit la zone en fonction de la taille, protège l'opération par un mutex, et déclenche le debug si MALLOC_DEBUG est activé. Toute la logique d'allocation est dans les helpers.

void   *malloc(size_t size)
{
 void     *ptr;

        if (size == 0)
                return (NULL);
        pthread_mutex_lock(&g_malloc.lock);
        if (size <= TINY_MAX)
                ptr = try_zone(&g_malloc.tiny, TINY, TINY_SIZE, size);
        else if (size <= SMALL_MAX)
                ptr = try_zone(&g_malloc.small, SMALL, SMALL_SIZE, size);
        else
                ptr = alloc_large(size);
        pthread_mutex_unlock(&g_malloc.lock);
        debug_malloc(ptr, size);
        return (ptr);
}

Ligne par ligne

1. if (size == 0) return (NULL); — La libc retourne soit NULL soit un pointeur unique valide pour free. On choisit NULL pour rester simple. À noter : on ne lock pas le mutex dans ce cas, optimisation mineure.
2. pthread_mutex_lock(&g_malloc.lock); — On acquiert le mutex avant de toucher aux listes. Sans ça, deux threads pourraient modifier g_malloc.tiny en même temps et corrompre la liste.
3. if (size <= TINY_MAX) — TINY_MAX = 128. Toute allocation ≤ 128 bytes va en zone TINY. On passe l'adresse de g_malloc.tiny (pointeur vers pointeur) pour pouvoir modifier la tête de liste si on crée une nouvelle zone.
4. else if (size <= SMALL_MAX) — SMALL_MAX = 1024. Allocations de 129 à 1024 bytes.
5. else ptr = alloc_large(size); — Au-delà de 1024 bytes, on mmap une zone dédiée. Pas de pré-allocation pour LARGE.
6. pthread_mutex_unlock(&g_malloc.lock); — On relâche le mutex avant le debug, pour ne pas le tenir pendant un write potentiellement long.
7. debug_malloc(ptr, size); — Affiche un message si MALLOC_DEBUG est activé. Sinon, no-op.

Flux d'allocation détaillé

try_zone : dispatcher interne

try_zone est un mini-dispatcher qui essaie d'abord l'allocation dans les zones existantes (try_existing), puis si ça échoue, crée une nouvelle zone (try_new). Cette séparation permet de garder la fonction sous 25 lignes (norme 42).

static void      *try_zone(t_zone **head, int type,
                                                size_t zsize, size_t size)
{
 void     *ptr;

        ptr = try_existing(*head, size);
        if (ptr != NULL)
                return (ptr);
        return (try_new(head, type, zsize, size));
}

try_existing : parcours des zones existantes

try_existing parcourt la liste chaînée des zones et, pour chaque zone, appelle find_block pour chercher un bloc libre assez grand. Dès qu'un bloc est trouvé, on le split et on retourne le pointeur utilisateur. Si aucune zone existante ne peut servir, on retourne NULL — try_zone créera alors une nouvelle zone.

static void      *try_existing(t_zone *head, size_t size)
{
 t_block  *block;

        while (head != NULL)
        {
                block = find_block(head, size);
                if (block != NULL)
                {
                        split_block(block, size);
                        return ((char *)block + sizeof(t_block));
                }
                head = head->next;
        }
        return (NULL);
}

Le return (char *)block + sizeof(t_block) mérite explication : on prend l'adresse du t_block, on la cast en char * (pour faire de l'arithmétique de bytes), et on ajoute sizeof(t_block) (32 bytes) — ce qui donne l'adresse du payload utilisateur. C'est ce pointeur que l'utilisateur reçoit.

find_block : recherche d'un bloc libre

find_block parcourt la liste chaînée des blocs d'une zone et retourne le premier bloc libre dont la taille est ≥ size + sizeof(t_block). Pourquoi size + sizeof(t_block) ? Parce qu'on veut pouvoir splitter le bloc trouvé : il faut assez de place pour le payload demandé plus un nouveau header pour le bloc restant. Si on exigeait juste size, on ne pourrait pas splitter et on aurait de la fragmentation interne (un bloc de 200 bytes servant une demande de 50 gaspille 150 bytes).

t_block      *find_block(t_zone *zone, size_t size)
{
 t_block  *block;

        block = zone->blocks;
        while (block != NULL)
        {
                if (block->free == FREE && block->size >= size + sizeof(t_block))
                        return (block);
                block = block->next;
        }
        return (NULL);
}

C'est un algorithme first-fit : on retourne le premier bloc qui convient. D'autres stratégies existent : best-fit (le plus petit bloc qui convient, moins de fragmentation interne mais plus de fragmentation externe), worst-fit (le plus gros bloc, contre-intuitif mais évite les petits blocs inutilisables). First-fit est un bon compromis et c'est ce que fait la glibc par défaut pour les petites allocations.

split_block : découpage

Quand find_block trouve un bloc libre assez grand, on appelle split_block pour le découper en deux : la première partie devient le bloc utilisé (taille = size), la seconde reste libre pour de futures allocations. On ne split que si l'espace restant est suffisant pour contenir un header + 8 bytes — sinon on garde le bloc entier (fragments internes acceptables, évite des micro-blocs inutilisables).

void   split_block(t_block *block, size_t size)
{
 t_block  *new;

        if (block->size > size + sizeof(t_block) + 8)
        {
                new = (t_block *)((char *)block
                                + sizeof(t_block) + size);
                new->size = block->size - size - sizeof(t_block);
                new->free = FREE;
                new->next = block->next;
                new->prev = block;
                if (block->next != NULL)
                        block->next->prev = new;
                block->next = new;
                block->size = size;
        }
        block->free = USED;
}

Ligne par ligne

1. if (block->size > size + sizeof(t_block) + 8) — On ne split que si le bloc original est assez grand pour contenir : le payload demandé (size) + un nouveau header (32 bytes) + au moins 8 bytes de payload pour le nouveau bloc. Sinon, on garde le bloc entier — mieux vaut 24 bytes de fragmentation interne qu'un micro-bloc inutilisable.
2. new = (t_block *)((char *)block + sizeof(t_block) + size); — On calcule l'adresse du nouveau header : adresse du bloc actuel + sizeof(t_block) (pour skipper le header actuel) + size (pour skipper le payload qu'on garde).
3. new->size = block->size - size - sizeof(t_block); — La taille du nouveau bloc = taille originale − taille qu'on prend − sizeof(t_block) (le header qu'on vient d'insérer).
4. new->free = FREE; — Le nouveau bloc est libre.
5. Mise à jour des pointeurs next/prev — On insère new entre block et block->next dans la liste doublement chaînée.
6. block->size = size; — Le bloc original est redimensionné à exactement size.
7. block->free = USED; — Marqué utilisé, que le split ait eu lieu ou non. Si on n'a pas splitté (pas assez de place), le bloc entier est utilisé.

try_new : création d'une nouvelle zone

Si try_existing n'a pas trouvé de place, on crée une nouvelle zone via create_zone. On l'insère en tête de liste (O(1), pas besoin de parcourir), puis on cherche un bloc dans cette zone fraîchement créée — il devrait toujours y en avoir un, puisqu'elle vient d'être créée.

static void      *try_new(t_zone **head, int type,
                                        size_t zsize, size_t size)
{
 t_zone   *zone;
 t_block  *block;

        zone = create_zone(type, zsize);
        if (zone == NULL)
                return (NULL);
        zone->next = *head;
        *head = zone;
        block = find_block(zone, size);
        if (block != NULL)
        {
                split_block(block, size);
                return ((char *)block + sizeof(t_block));
        }
        return (NULL);
}

create_zone : appel à mmap

create_zone est la fonction qui appelle réellement mmap. Elle demande une région de zone_size bytes (16384 ou 131072), initialise le header t_zone, et crée le premier t_block qui occupe toute la zone restante (libre, prêt à être splitté).

t_zone       *create_zone(int type, size_t zone_size)
{
 t_zone   *zone;

        zone = mmap(NULL, zone_size, PROT_READ | PROT_WRITE,
                                MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
        if (zone == MAP_FAILED)
                return (NULL);
        zone->type = type;
        zone->size = zone_size;
        zone->next = NULL;
        zone->blocks = (t_block *)((char *)zone + sizeof(t_zone));
        zone->blocks->size = zone_size - sizeof(t_zone) - sizeof(t_block);
        zone->blocks->free = FREE;
        zone->blocks->next = NULL;
        zone->blocks->prev = NULL;
        return (zone);
}

Notez l'initialisation du premier bloc : sa taille est zone_size - sizeof(t_zone) - sizeof(t_block) — toute la zone moins les deux headers. Il est marqué FREE, prêt à être splitté par le premier malloc qui en a besoin.

alloc_large : cas spécial

Pour les allocations > 1024 bytes, on ne split pas : on demande directement au noyau une région de la bonne taille (arrondie au multiple de getpagesize() supérieur). Cette zone est insérée en tête de la liste LARGE, et libérée individuellement par munmap au moment du free.

void   *alloc_large(size_t size)
{
 size_t   total;
 t_zone   *zone;

        total = size + sizeof(t_zone) + sizeof(t_block);
        total = (total / getpagesize() + 1) * getpagesize();
        zone = mmap(NULL, total, PROT_READ | PROT_WRITE,
                                MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
        if (zone == MAP_FAILED)
                return (NULL);
        zone->type = LARGE;
        zone->size = total;
        zone->next = g_malloc.large;
        zone->blocks = (t_block *)((char *)zone + sizeof(t_zone));
        zone->blocks->size = size;
        zone->blocks->free = USED;
        zone->blocks->next = NULL;
        zone->blocks->prev = NULL;
        g_malloc.large = zone;
        return ((char *)zone->blocks + sizeof(t_block));
}

Trace d'une séquence d'appels

Prenons une séquence concrète et traçons ce qui se passe dans notre allocateur. Supposons que g_malloc est vide au départ (aucune zone). Note : les adresses sont simplifiées pour la lisibilité (en réalité, mmap retourne des adresses dans la plage 0x7f... sur Linux x86-64).

// État initial : g_malloc = { tiny=NULL, small=NULL, large=NULL, mutex }

malloc(50)   // 50 ≤ 128 → TINY
  // try_zone(&g_malloc.tiny, TINY, 16384, 50)
  // try_existing : g_malloc.tiny == NULL, rien à parcourir, retourne NULL
  // try_new : create_zone(TINY, 16384) → mmap(16384) → zone à 0x1000
  //   zone->blocks = 0x1020, size = 16384-32-32 = 16320, free=FREE
  // find_block(zone, 50) → retourne 0x1020 (seul bloc, libre, size 16320 ≥ 82)
  // split_block(0x1020, 50) :
  //   new = 0x1020 + 32 + 50 = 0x1072
  //   new->size = 16320 - 50 - 32 = 16238, free=FREE
  //   block->size = 50, free=USED
  // return 0x1020 + 32 = 0x1040  ← USER PTR
  // g_malloc.tiny = 0x1000

malloc(100)  // 100 ≤ 128 → TINY
  // try_existing : parcours zone 0x1000
  // find_block : 0x1020 USED (non), 0x1072 FREE size 16238 ≥ 132 → OUI
  // split_block(0x1072, 100) :
  //   new = 0x1072 + 32 + 100 = 0x10F6
  //   new->size = 16238 - 100 - 32 = 16106, free=FREE
  // return 0x1072 + 32 = 0x1092  ← USER PTR

malloc(5000) // 5000 > 1024 → LARGE
  // alloc_large(5000) :
  //   total = 5000 + 32 + 32 = 5064
  //   total = (5064/4096 + 1) × 4096 = 8192
  //   mmap(8192) → zone à 0x5000
  //   blocks->size = 5000, free=USED
  // return 0x5000 + 32 + 32 = 0x5040  ← USER PTR
  // g_malloc.large = 0x5000

// État final :
// g_malloc.tiny  → [zone 0x1000][block USED 50B][block USED 100B][block FREE 16106B]
// g_malloc.large → [zone 0x5000][block USED 5000B]

La fonction free(void *ptr) doit identifier la zone contenant le pointeur, libérer le bloc correspondant, et — pour les zones TINY/SMALL — fusionner le bloc avec ses voisins libres pour éviter la fragmentation. Pour les zones LARGE, la zone entière est retournée au noyau via munmap. Le défi majeur est de retrouver la zone d'appartenance d'un pointeur arbitraire en O(zones) et non O(blocs).

Le défi : retrouver la zone

Quand l'utilisateur appelle free(ptr), notre allocateur reçoit juste un pointeur — sans information sur la taille ou la zone. La structure t_block est juste avant le payload (à ptr - sizeof(t_block)), donc on peut retrouver le bloc en O(1). Mais pour trouver la zone (nécessaire pour savoir si c'est TINY, SMALL ou LARGE, et pour munmap si LARGE), on doit parcourir les listes de zones et vérifier si ptr tombe dans l'intervalle [zone, zone + zone->size].

search_zones : parcours

search_zones prend une tête de liste et un pointeur, et retourne la zone qui contient le pointeur (ou NULL). On utilise des comparaisons strictes : > et <, pas >= / <=, car ptr == zone pointerait sur le header t_zone lui-même (invalide), et ptr == zone + zone->size pointerait juste après la zone (dans la zone suivante ou hors mmap).

t_zone       *search_zones(t_zone *head, void *ptr)
{
        while (head != NULL)
        {
                if ((char *)ptr > (char *)head
                        && (char *)ptr < (char *)head + head->size)
                        return (head);
                head = head->next;
        }
        return (NULL);
}

find_zone : dispatch TINY/SMALL/LARGE

find_zone essaie search_zones sur TINY, puis SMALL, puis LARGE. On retourne dès qu'on trouve. Si aucune zone ne contient le pointeur, on retourne NULL — free ignorera silencieusement le pointeur (comportement standard de la libc qui ne crash pas sur free(NULL) ou free(ptr_étranger)).

static t_zone    *find_zone(void *ptr)
{
 t_zone   *zone;

        zone = search_zones(g_malloc.tiny, ptr);
        if (zone != NULL)
                return (zone);
        zone = search_zones(g_malloc.small, ptr);
        if (zone != NULL)
                return (zone);
        return (search_zones(g_malloc.large, ptr));
}

Défragmentation (merge)

Une fois le bloc marqué FREE, on essaie de le fusionner avec son voisin suivant (merge_next) puis avec son voisin précédent (merge_prev). Cette défragmentation maximise la taille des blocs libres consécutifs, ce qui évite les échecs d'allocation futures par manque de bloc assez grand — malgré une quantité totale de mémoire libre suffisante. C'est le problème classique de la fragmentation externe.

void   merge_next(t_block *block)
{
        if (block->next != NULL && block->next->free == FREE)
        {
                block->size += block->next->size + sizeof(t_block);
                block->next = block->next->next;
                if (block->next != NULL)
                        block->next->prev = block;
        }
}

Ligne par ligne

1. if (block->next != NULL && block->next->free == FREE) — On ne merge que si le bloc suivant existe ET est libre. Pas de merge si c'est le dernier bloc de la zone, ou si le suivant est utilisé.
2. block->size += block->next->size + sizeof(t_block); — La nouvelle taille = taille actuelle + taille du suivant + sizeof(t_block) (le header du suivant disparaît, son espace devient payload).
3. block->next = block->next->next; — On skip le bloc fusionné dans la liste chaînée.
4. if (block->next != NULL) block->next->prev = block; — On met à jour le prev du bloc suivant (qui est maintenant le bloc courant). Si le bloc suivant est NULL (on a fusionné le dernier), pas de mise à jour.

void   merge_prev(t_block *block)
{
        if (block->prev != NULL && block->prev->free == FREE)
        {
                block->prev->size += block->size + sizeof(t_block);
                block->prev->next = block->next;
                if (block->next != NULL)
                        block->next->prev = block->prev;
        }
}

merge_prev est symétrique : on étend le bloc précédent pour qu'il absorbe le bloc courant. Notez qu'après merge_prev, le pointeur block devient invalide (son espace est maintenant occupé par block->prev) — mais on n'y accède plus après, donc c'est OK.

munmap pour LARGE

Les zones LARGE ne sont pas défragmentées (chaque zone ne contient qu'un seul bloc). Au lieu de cela, on retire la zone de la liste chaînée et on appelle munmap(zone, zone->size) pour rendre la mémoire au noyau. C'est le seul cas où un free réduit réellement l'empreinte mémoire du processus — les frees TINY/SMALL marquent juste les blocs comme réutilisables, sans rendre la mémoire au système.

void   remove_large_zone(t_zone *zone)
{
 t_zone   *cur;
 t_zone   *prev;

        cur = g_malloc.large;
        prev = NULL;
        while (cur != NULL)
        {
                if (cur == zone)
                {
                        if (prev != NULL)
                                prev->next = cur->next;
                        else
                                g_malloc.large = cur->next;
                        munmap(zone, zone->size);
                        return ;
                }
                prev = cur;
                cur = cur->next;
        }
}

Pourquoi un parcours linéaire ?

On pourrait penser que remove_large_zone est inutile : on connaît déjà zone, pourquoi reparcourir la liste ? Parce qu'on a besoin de prev pour mettre à jour prev->next — et notre structure t_zone n'a pas de pointeur prev (contrairement à t_block). On aurait pu ajouter un prev à t_zone pour O(1), mais ça ajouterait 8 bytes par zone (sur 32 bytes de header, c'est 25% d'overhead). Compromis : O(zones) pour le free LARGE, mais les zones LARGE sont rares (une par alloc > 1024B), donc acceptable.

Fonction free complète

void   free(void *ptr)
{
 t_zone   *zone;
 t_block  *block;

        if (ptr == NULL)
                return ;
        pthread_mutex_lock(&g_malloc.lock);
        zone = find_zone(ptr);
        if (zone == NULL)
        {
                pthread_mutex_unlock(&g_malloc.lock);
                return ;
        }
        block = (t_block *)((char *)ptr - sizeof(t_block));
        if (zone->type == LARGE)
                remove_large_zone(zone);
        else
        {
                block->free = FREE;
                merge_next(block);
                merge_prev(block);
        }
        debug_free(ptr);
        pthread_mutex_unlock(&g_malloc.lock);
}

Ligne par ligne

1. if (ptr == NULL) return ; — Comportement standard de la libc : free(NULL) est un no-op. On ne lock même pas le mutex — optimisation mineure mais juste.
2. pthread_mutex_lock(&g_malloc.lock); — On protège les listes de zones. Sans ça, un autre thread pourrait faire un malloc qui modifie g_malloc.tiny pendant qu'on lit.
3. zone = find_zone(ptr); — On cherche la zone contenant ptr. Peut retourner NULL si le pointeur est étranger (stack, data, ou libc malloc).
4. if (zone == NULL) — On relâche le mutex et on retourne silencieusement. Pas de crash, pas d'erreur — la libc fait pareil.
5. block = (t_block *)((char *)ptr - sizeof(t_block)); — On retrouve le header t_block en soustrayant sizeof(t_block) au pointeur utilisateur. Cast en char * pour l'arithmétique de bytes.
6. if (zone->type == LARGE) remove_large_zone(zone); — Pour LARGE, on munmap la zone entière.
7. else { block->free = FREE; merge_next(block); merge_prev(block); } — Pour TINY/SMALL, on marque le bloc libre et on fusionne avec les voisins libres.
8. debug_free(ptr); — Affiche un message si MALLOC_DEBUG est activé.
9. pthread_mutex_unlock(&g_malloc.lock); — On relâche le mutex.

realloc(ptr, size) redimensionne une allocation. C'est la fonction la plus subtile du projet, avec quatre cas particuliers à gérer explicitement. Cette section décortique chaque cas et explique pourquoi on ne tente pas d'extension in-place (contrairement à la glibc).

Les quatre cas

void   *realloc(void *ptr, size_t size)
{
 void     *new;
 size_t   old_size;

        if (ptr == NULL)
                return (malloc(size));
        if (size == 0)
        {
                free(ptr);
                return (NULL);
        }
        old_size = get_block_size(ptr);
        if (size <= old_size)
                return (ptr);
        new = malloc(size);
        if (new == NULL)
                return (NULL);
        copy_data(new, ptr, old_size);
        free(ptr);
        return (new);
}

Ligne par ligne

1. if (ptr == NULL) return (malloc(size)); — Cas 1. realloc(NULL, n) est équivalent à malloc(n) selon la norme C.
2. if (size == 0) { free(ptr); return (NULL); } — Cas 2. realloc(ptr, 0) libère ptr et retourne NULL. C'est ce que teste le test5 du sujet.
3. old_size = get_block_size(ptr); — On récupère l'ancienne taille en lisant le header t_block avant le payload.
4. if (size <= old_size) return (ptr); — Cas 3. Si la nouvelle taille est inférieure ou égale, on retourne le même pointeur sans rien faire. C'est une optimisation : on ne shrink pas (ça créerait des micro-blocs), on garde juste le bloc tel quel. Le test4 vérifie ça : realloc(s, 4) après malloc(16) retourne le même pointeur.
5. new = malloc(size); — Cas 4. On alloue un nouveau bloc plus grand.
6. if (new == NULL) return (NULL); — Si malloc échoue, on retourne NULL sans libérer ptr. C'est le comportement standard : l'appelant peut toujours utiliser ptr avec l'ancienne taille.
7. copy_data(new, ptr, old_size); — On copie les anciennes données vers le nouveau bloc. On copie old_size bytes, pas size — sinon on lirait au-delà du bloc source.
8. free(ptr); — On libère l'ancien bloc.
9. return (new); — On retourne le nouveau pointeur.

Pourquoi pas d'extension in-place ?

La glibc, quand on fait realloc(ptr, larger_size), essaie d'abord d'étendre le bloc actuel : si le bloc suivant est libre et assez grand, elle le merge et retourne le même pointeur. C'est beaucoup plus rapide que malloc + copy + free. Notre implémentation ne fait pas ça — pourquoi ? Parce que c'est complexe à implémenter correctement (il faut vérifier que le bloc suivant est libre, qu'il est assez grand, gérer le cas où il l'est mais pas assez, etc.), et le sujet ne l'exige pas. La glibc a 5000 lignes pour ça ; nous en avons 20. Compromis acceptable.

get_block_size : lire l'ancienne taille

get_block_size est un helper trivial : on retrouve le header t_block en soustrayant sizeof(t_block) au pointeur, et on retourne block->size. C'est le pendant de ce qu'on fait dans free.

static size_t    get_block_size(void *ptr)
{
 t_block  *block;

        block = (t_block *)((char *)ptr - sizeof(t_block));
        return (block->size);
}

copy_data : copie manuelle

La fonction copy_data est une copie byte-à-byte manuelle (on n'a pas droit à memcpy ou memmove). On copie old_size bytes — jamais size, sinon on lirait au-delà du bloc source (undefined behavior).

static void      copy_data(void *dst, void *src, size_t size)
{
 char     *d;
 char     *s;
 size_t   i;

        d = dst;
        s = src;
        i = 0;
        while (i < size)
        {
                d[i] = s[i];
                i++;
        }
}

realloc et threads

realloc n'acquiert pas le mutex lui-même — elle appelle malloc et free qui gèrent chacun leur propre lock. C'est important pour éviter les deadlocks : si realloc prenait le lock, puis appellerait malloc qui essaierait de re-prendre le lock, ça serait un deadlock (le mutex normal n'est pas réentrant). Notre design évite ça en ne lockant qu'au niveau des opérations atomiques (malloc, free).

calloc(count, size) est un bonus qui alloue count × size bytes initialisés à zéro. Contrairement à malloc, la mémoire retournée est garantie nulle — ce qui est attendu par beaucoup de programmes C pour initialiser des structures. Cette section explique la vérification d'overflow, qui est le point critique de calloc.

Différence avec malloc

malloc(n) retourne n bytes non initialisés (en pratique, souvent zéroés par mmap, mais pas garanti — si la zone est réutilisée après un free, elle contient les anciennes données). calloc(count, size) retourne count × size bytes garantis zéro. C'est plus sûr pour initialiser des structures sans comportement indéfini. La différence principale dans l'implémentation : calloc doit explicitement écrire des zéros, alors que malloc peut skipper cette étape.

Le piège de l'overflow

count × size peut déborder un size_t si count et size sont grands. Par exemple, calloc(SIZE_MAX/2, 3) va déborder et donner un petit nombre, puis malloc allouera une petite zone — mais l'utilisateur pensera en avoir une grande. C'est un classique piège de sécurité exploitable via un débordement arithmétique dans count × size. Plusieurs CVE historiques sont liées à ce pattern (par exemple CVE-2018-6954 dans sudo, ou divers décodeurs d'images qui allouaient un buffer trop petit puis écrivaient au-delà).

La vérification standard : if (count != 0 && total / count != size). On divise le total par count, et si on ne retrouve pas size, c'est qu'il y a eu overflow. Pourquoi count != 0 ? Pour éviter la division par zéro (si count == 0, on retourne NULL avant).

void   *calloc(size_t count, size_t size)
{
 void     *ptr;
 size_t   total;
 char     *p;
 size_t   i;

        total = count * size;
        if (total == 0)
                return (NULL);
        if (count != 0 && total / count != size)
                return (NULL);
        ptr = malloc(total);
        if (ptr == NULL)
                return (NULL);
        p = ptr;
        i = 0;
        while (i < total)
        {
                p[i] = 0;
                i++;
        }
        return (ptr);
}

Ligne par ligne

1. total = count * size; — On calcule le produit. Peut overflow silencieusement.
2. if (total == 0) return (NULL); — Si count ou size est 0, on retourne NULL. Comportement standard de la libc.
3. if (count != 0 && total / count != size) return (NULL); — La vérification d'overflow. Si le produit a débordé, total / count ne redonnera pas size. On retourne NULL au lieu d'allouer une taille erronée.
4. ptr = malloc(total); — On alloue via notre malloc.
5. if (ptr == NULL) return (NULL); — Propagation de l'erreur.
6. p = ptr; i = 0; while (i < total) { p[i] = 0; i++; } — On initialise tous les bytes à zéro. On utilise un cast en char * pour itérer byte par byte.
7. return (ptr); — On retourne le pointeur.

Pourquoi initialiser à 0 ?

Trois raisons : (1) sécurité — si on réutilise un bloc précédemment libéré, il contient les anciennes données. Un programme qui alloue une structure et ne remplit que certains champs peut fuiter des données sensibles à travers les champs non initialisés. (2) prédictibilité — beaucoup de bugs subtiles viennent de structures partiellement initialisées. calloc garantit un état de départ propre. (3) comportement standard — la norme C exige que calloc retourne de la mémoire zeroed ; ne pas le faire casserait des programmes qui dépendent de ce contrat.

show_alloc_mem affiche l'état des zones mémoire dans un format imposé par le sujet : par adresses croissantes, avec le type de zone, l'adresse de début, et pour chaque bloc utilisé l'intervalle [start - end] : N bytes. La fonction se termine par un total. Cette section explique le format, les helpers ft_* réécrits (car printf est interdit), et la conversion hexadécimale.

Le format imposé

Le sujet donne un exemple précis de sortie. Il faut le respecter à la lettre : TINY : 0x... (avec espace autour des deux-points), 0x... - 0x... : N bytes (avec espaces autour des deux-points et du tiret), Total : N bytes en bas. Les adresses en hexadécimal minuscule préfixé de 0x. Les blocs triés par ordre croissant d'adresse (ce qui est naturel si on parcourt la liste chaînée dans l'ordre ; dans la pratique sur Linux, mmap retourne des adresses décroissantes, donc l'ordre LIFO d'insertion correspond à l'ordre croissant).

TINY : 0xA0000
0xA0020 - 0xA004A : 42 bytes
0xA006A - 0xA00BE : 84 bytes
SMALL : 0xAD000
0xAD020 - 0xADEAD : 3725 bytes
LARGE : 0xB0000
0xB0020 - 0xBBEEF : 48847 bytes
Total : 52698 bytes

La fonction principale

void   show_alloc_mem(void)
{
 size_t   total;

        total = 0;
        total += show_zone(g_malloc.tiny, "TINY");
        total += show_zone(g_malloc.small, "SMALL");
        total += show_zone(g_malloc.large, "LARGE");
        ft_putstr("Total : ");
        ft_putnbr(total);
        ft_putstr(" bytes\n");
}

show_zone : parcours d'une catégorie

show_zone affiche l'en-tête TINY : 0x... (ou SMALL, LARGE), puis parcourt toutes les zones de cette catégorie et, pour chaque zone, tous les blocs. Pour chaque bloc USED, on appelle print_block. On accumule le total dans une variable passée par pointeur (pour éviter un return value qui compliquerait le code).

static size_t    show_zone(t_zone *zone, char *name)
{
 t_block  *block;
 size_t   total;

        total = 0;
        if (zone == NULL)
                return (0);
        ft_putstr(name);
        ft_putstr(" : ");
        ft_putaddr(zone);
        ft_putstr("\n");
        while (zone != NULL)
        {
                block = zone->blocks;
                while (block != NULL)
                {
                        print_block(block, &total);
                        block = block->next;
                }
                zone = zone->next;
        }
        return (total);
}

print_block : affichage d'un bloc

print_block est un helper qui factorise l'affichage d'un bloc USED. On skip les blocs FREE (le sujet ne demande d'afficher que les blocs utilisés dans show_alloc_mem). Pour chaque bloc USED, on affiche start - end : N bytes où start = ptr utilisateur, end = start + size, N = size.

static void      print_block(t_block *block, size_t *total)
{
        if (block->free != USED)
                return ;
        ft_putaddr((char *)block + sizeof(t_block));
        ft_putstr(" - ");
        ft_putaddr((char *)block + sizeof(t_block) + block->size);
        ft_putstr(" : ");
        ft_putnbr(block->size);
        ft_putstr(" bytes\n");
        *total += block->size;
}

Sortie réelle sur test6 :

TINY : 0x7fbe3bc86000
0x7fbe3bc86040 - 0x7fbe3bc8604a : 10 bytes
0x7fbe3bc8606a - 0x7fbe3bc860ce : 100 bytes
0x7fbe3bc860ee - 0x7fbe3bc86120 : 50 bytes
LARGE : 0x7fbe3bc84000
0x7fbe3bc84040 - 0x7fbe3bc853c8 : 5000 bytes
Total : 5160 bytes

Les helpers ft_*

Pour éviter de réécrire ft_putstr, ft_putnbr, ft_putaddr dans chaque fichier d'affichage (ce qui violerait la règle des 5 fonctions par fichier), ces helpers sont centralisés dans ft_utils.c et déclarés extern dans malloc.h. Les trois fichiers d'affichage (show_alloc_mem.c, show_alloc_mem_ex.c, debug.c) les réutilisent.

ft_putstr

void   ft_putstr(char *s)
{
 int      i;

        i = 0;
        while (s[i] != '\0')
                i++;
        write(1, s, i);
}

On calcule d'abord la longueur, puis on appelle write une seule fois. Pourquoi pas un write(1, &s[i], 1) dans la boucle ? Parce que chaque write est un syscall coûteux (~1 µs). Pour une string de 50 caractères, ce serait 50 µs au lieu de 1 µs. Sur show_alloc_mem qui affiche beaucoup de strings, la différence est notable.

ft_putnbr : décimal

void   ft_putnbr(size_t n)
{
 char     c;

        if (n >= 10)
                ft_putnbr(n / 10);
        c = '0' + (n % 10);
        write(1, &c, 1);
}

Récursif : on divise par 10 jusqu'à ce que n < 10, puis on affiche les chiffres dans l'ordre (le dernier appel récursif affiche le chiffre le plus significatif en premier). Pour 5160 : ft_putnbr(516) → ft_putnbr(51) → ft_putnbr(5) → affiche '5', puis '1', puis '6', puis '0'. Résultat : "5160".

ft_putaddr : hexadécimal

ft_putaddr convertit un pointeur en hexadécimal minuscule préfixé de 0x. On utilise un buffer de 20 caractères (large marge : 64 bits = 16 chiffres hex + "0x" = 18 bytes nécessaires) qu'on remplit par le bas, puis on affiche à l'envers (puisque la division donne les chiffres dans l'ordre inverse).

void   ft_putaddr(void *addr)
{
 size_t   n;
 char     buf[20];
 int              i;

        n = (size_t)addr;
        i = 0;
        if (n == 0)
        {
                write(1, "0x0", 3);
                return ;
        }
        while (n > 0)
        {
                buf[i] = "0123456789abcdef"[n % 16];
                i++;
                n /= 16;
        }
        write(1, "0x", 2);
        while (i > 0)
        {
                i--;
                write(1, &buf[i], 1);
        }
}

Ligne par ligne

1. n = (size_t)addr; — On convertit le pointeur en entier non signé. Sur 64 bits, size_t = 8 bytes, comme un pointeur. Le cast est safe.
2. if (n == 0) { write(1, "0x0", 3); return ; } — Cas spécial : pointeur NULL. On affiche "0x0" et on return (sinon la boucle while (n > 0) ne s'exécuterait pas et on n'afficherait que "0x").
3. buf[i] = "0123456789abcdef"[n % 16]; — Astuce classique : on indexe directement dans une string littérale. n % 16 donne un chiffre hex (0-15), et on prend le caractère correspondant dans "0123456789abcdef".
4. n /= 16; — On passe au chiffre suivant (digit hex suivant, vers la gauche).
5. write(1, "0x", 2); — On affiche le préfixe.
6. while (i > 0) { i--; write(1, &buf[i], 1); } — On affiche les chiffres dans l'ordre inverse (le buffer a été rempli du moins significatif au plus significatif, donc on lit de la fin vers le début).

ft_putsize : hexadécimal sans préfixe

ft_putsize est similaire à ft_putaddr mais sans le préfixe 0x et sans le cas spécial NULL. Utilisée par debug_malloc pour afficher la taille en hex (par exemple size=a pour 10 bytes).

void   ft_putsize(size_t size)
{
 char     buf[20];
 size_t   n;
 int              i;

        n = size;
        i = 0;
        if (n == 0)
        {
                write(1, "0", 1);
                return ;
        }
        while (n > 0)
        {
                buf[i] = "0123456789abcdef"[n % 16];
                i++;
                n /= 16;
        }
        while (i > 0)
        {
                i--;
                write(1, &buf[i], 1);
        }
}

Le sujet propose plusieurs bonus évalués uniquement si le mandatory est excellent. Notre implémentation couvre cinq bonus : thread-safety, show_alloc_mem_ex (hex dump), variables d'environnement de debug, défragmentation, et calloc. Cette section détaille chacun.

Bonus 1 : show_alloc_mem_ex()

Version étendue de show_alloc_mem qui ajoute pour chaque bloc : un tag [USED] ou [FREE], et pour les blocs utilisés, un hex dump des 32 premiers bytes du payload. Utile pour debugger des corruptions mémoire (buffer overflow, use-after-free).

static void      hex_dump(void *ptr, size_t size)
{
 unsigned char    *p;
size_t                    i;

        p = (unsigned char *)ptr;
        i = 0;
        while (i < size && i < 32)
        {
                ft_putaddr((void *)(size_t)p[i]);
                write(1, " ", 1);
                i++;
        }
        write(1, "\n", 1);
}

Astuce : réutiliser ft_putaddr

Pour afficher un byte en hex, on réutilise ft_putaddr en castant le byte en void *. C'est hacky — ft_putaddr affichera "0x41" pour le byte 0x41, avec le préfixe "0x". Pour un hex dump compact, on préférerait "41 " sans préfixe, mais ça aurait nécessité une fonction ft_puthex séparée, qui aurait compté dans la limite des 5 fonctions par fichier. Compromis : on accepte le "0x" superflu.

Sortie réelle :

TINY : 0x7fbe3bc86000
[USED]  0x7fbe3bc86040 - 0x7fbe3bc8604a : 10 bytes
0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
[USED]  0x7fbe3bc8606a - 0x7fbe3bc860ce : 100 bytes
0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 ...
[USED]  0x7fbe3bc860ee - 0x7fbe3bc86120 : 50 bytes
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 ...
[FREE]  0x7fbe3bc86140 - 0x7fbe3bc8a000 : 16064 bytes
LARGE : 0x7fbe3bc84000
[USED]  0x7fbe3bc84040 - 0x7fbe3bc853c8 : 5000 bytes
0x43 0x43 0x43 0x43 0x43 0x43 0x43 0x43 0x43 0x43 ...
Total : 5160 bytes

On voit clairement les 0x41 ('A'), les 0x42 ('B'), les 0x43 ('C') et les 0x44 ('D') que test6.c écrit dans ses allocations. Et le grand bloc [FREE] de 16064 bytes est l'espace restant dans la zone TINY après les splits.

Bonus 2 : MALLOC_DEBUG

La variable MALLOC_DEBUG=1 (ou y, Y) active l'affichage de chaque appel à malloc et free avec le pointeur et la taille. La détection est mise en cache dans une variable statique pour éviter un getenv à chaque appel.

static int       debug_enabled(void)
{
   static int initialized = 0;
   static int enabled = 0;
 char             *env;
int                       i;

        if (initialized == 0)
        {
                env = getenv("MALLOC_DEBUG");
                if (env != NULL)
                {
                        i = 0;
                        while (env[i] != '\0')
                        {
                                if (env[i] == '1' || env[i] == 'y'
                                        || env[i] == 'Y')
                                        enabled = 1;
                                i++;
                        }
                }
                initialized = 1;
        }
        return (enabled);
}

Pourquoi un cache ?

getenv parcourt le tableau environ à chaque appel — O(n) où n est le nombre de variables d'environnement. Sur un processus typique avec 50 variables, c'est 50 comparaisons de strings par appel. Pour un programme qui fait 10000 malloc/free, c'est 500000 comparaisons. Avec le cache, on fait getenv une seule fois (premier appel), puis on lit juste un int — O(1). Note : ce cache n'est pas thread-safe (race sur initialized au premier appel), mais c'est acceptable pour du debug — au pire, deux threads font le getenv en parallèle, ce qui est inoffensif.

$ export MALLOC_DEBUG=1
$ ./run.sh ./tests/test6
[MALLOC_DEBUG] malloc ptr=0x7f66da60b040 size=a
[MALLOC_DEBUG] malloc ptr=0x7f66da60b06a size=64
[MALLOC_DEBUG] malloc ptr=0x7f66da609040 size=1388
[MALLOC_DEBUG] malloc ptr=0x7f66da60b0ee size=32
TINY : 0x7f66da60b000
0x7f66da60b040 - 0x7f66da60b04a : 10 bytes
...

Notez que les tailles sont en hexadécimal (0xa = 10, 0x64 = 100, 0x1388 = 5000). C'est parce qu'on réutilise ft_putsize qui affiche en hex (pour rester cohérent avec ft_putaddr). On aurait pu utiliser ft_putnbr pour le décimal, mais le debug en hex est plus compact et facilite la corrélation avec les adresses.

Bonus 3 : Défragmentation (déjà couvert)

La défragmentation est implémentée dans free_utils.c via merge_next et merge_prev, appelées systématiquement après chaque free sur une zone TINY ou SMALL. Voir la section 06 · free() pour le détail du mécanisme et un diagramme du résultat.

Bonus 4 : calloc()

calloc est techniquement un bonus — voir la section 08 · calloc() pour le détail. C'est le bonus le plus simple : malloc(count × size) + vérification d'overflow + memset à 0.

Récapitulatif des bonus

Note thread-safe 4/5 au lieu de 5/5 : le mutex manque dans show_alloc_mem et show_alloc_mem_ex. C'est un défaut mineur (ces fonctions sont pour le debug, rarement appelées en multi-thread), mais un correcteur strict le remarquera.

Le sujet autorise explicitement une seconde globale pour gérer la thread-safety. Plutôt qu'une globale séparée, nous avons intégré le mutex directement dans la structure t_malloc — initialisé statiquement avec PTHREAD_MUTEX_INITIALIZER, ce qui évite tout appel explicite à pthread_mutex_init avant la première utilisation. Cette section explique en profondeur les choix de design, les pièges (deadlock, initialisation paresseuse), et les performances.

Pourquoi un mutex ?

Si deux threads appellent malloc en même temps, ils peuvent tous les deux lire g_malloc.tiny en même temps, trouver la même zone, et tous les deux essayer de modifier la liste chaînée des blocs. Résultat : liste corrompue, blocs perdus, double-allocation du même espace. C'est un data race — comportement indéfini selon la norme C11.

La solution standard : un mutex (mutual exclusion). Un mutex est un objet qui ne peut être tenu que par un thread à la fois. pthread_mutex_lock bloque jusqu'à ce que le mutex soit disponible ; pthread_mutex_unlock le relâche. Entre les deux, le thread a l'exclusivité sur les données protégées.

PTHREAD_MUTEX_INITIALIZER vs pthread_mutex_init

Deux façons d'initialiser un mutex : (1) statiquement avec PTHREAD_MUTEX_INITIALIZER — le mutex est valide dès la compilation, aucune fonction à appeler ; (2) dynamiquement avec pthread_mutex_init(&mutex, NULL) — il faut appeler cette fonction avant la première utilisation, et pthread_mutex_destroy à la fin.

Pour notre allocateur, l'initialisation statique est obligatoire. Pourquoi ? Parce que le loader appelle malloc avant main — pour initialiser les buffers stdio, par exemple. À ce moment-là, aucun code d'initialisation utilisateur n'a tourné. Si on utilisait pthread_mutex_init, il faudrait l'appeler avant le premier malloc — mais qui l'appelle ? Personne. Le premier malloc utiliserait un mutex non initialisé → comportement indéfini (souvent un crash).

t_malloc     g_malloc = {NULL, NULL, NULL,
                        PTHREAD_MUTEX_INITIALIZER};

Deadlock : comment l'éviter

Un deadlock survient quand deux threads s'attendent mutuellement. Cas classique : thread A lock M1 puis essaie de lock M2, tandis que thread B lock M2 puis essaie de lock M1. Les deux bloquent indéfiniment. Notre allocateur a un seul mutex (g_malloc.lock), donc ce cas est impossible — pas de deadlock inter-mutex.

Mais il y a un autre piège : le self-deadlock. Si un thread lock le mutex, puis appelle une fonction qui re-lock le mutex, il se bloque lui-même. Les mutex par défaut ne sont pas réentrant (ne peuvent pas être lockés deux fois par le même thread). Notre design évite ça en ne lockant qu'au niveau des opérations atomiques :

• malloc lock, fait son travail, unlock.
• free lock, fait son travail, unlock.
• realloc ne lock pas — il appelle malloc et free qui gèrent chacun leur lock.
• calloc ne lock pas — il appelle malloc qui lock.

Si realloc lockait, puis appellerait malloc qui essaierait de re-locker → self-deadlock. Notre design évite ça en laissant le lock au niveau le plus bas.

Performance : coût du mutex

Un pthread_mutex_lock + unlock coûte environ 25 nanosecondes sur un CPU moderne (en l'absence de contention). Pour un malloc qui prend 50 ns sans lock, le mutex double le temps. C'est pourquoi la glibc utilise des arenas multiples (un pool de mutex par thread) pour réduire la contention — mais c'est complexe à implémenter. Pour notre projet, un seul mutex suffit ; la contention est acceptable pour des programmes typiques.

Pourquoi pas un spinlock ?

Un spinlock est un lock où le thread attend en bouclant activement (busy-wait) plutôt qu'en dormant. Avantage : pas de transition kernel (qui coûte ~1 µs). Inconvénient : gaspille du CPU pendant l'attente. Pour des sections critiques très courtes (< 1 µs), le spinlock gagne. Pour des sections longues ou très contended, le mutex (qui endort le thread) est meilleur. Notre section critique est courte (50-100 ns), donc spinlock serait théoriquement mieux — mais pthread ne fournit pas de spinlock portable (c'est une extension POSIX), et la norme 42 n'autorise que pthread. On reste sur mutex.

Le Makefile doit produire une bibliothèque partagée libft_malloc_$HOSTTYPE.so et un lien symbolique libft_malloc.so. Il doit gérer le cas où la variable d'environnement $HOSTTYPE est vide ou inexistante en lui assignant $(shell uname -m)_$(shell uname -s) (par exemple x86_64_Linux). Cette section explique chaque flag de compilation et le script run.sh pour tester avec LD_PRELOAD.

Le Makefile complet

# Détection HOSTTYPE si vide
ifeq ($(HOSTTYPE),)
    HOSTTYPE := $(shell uname -m)_$(shell uname -s)
endif

NAME    = libft_malloc_$(HOSTTYPE).so
LINK    = libft_malloc.so

CC      = cc
CFLAGS  = -Wall -Wextra -Werror -fPIC -g
LDFLAGS = -shared -pthread

INCLUDES = -I includes

SRCS_DIR = srcs
SRCS     = $(SRCS_DIR)/malloc.c \
          $(SRCS_DIR)/zone_helpers.c \
          $(SRCS_DIR)/free.c \
          $(SRCS_DIR)/free_utils.c \
          $(SRCS_DIR)/realloc.c \
          $(SRCS_DIR)/calloc.c \
          $(SRCS_DIR)/show_alloc_mem.c \
          $(SRCS_DIR)/show_alloc_mem_ex.c \
          $(SRCS_DIR)/ft_utils.c \
          $(SRCS_DIR)/debug.c

OBJS    = $(SRCS:.c=.o)
HEADERS = includes/malloc.h

.PHONY: all clean fclean re test

all:        $(NAME) $(LINK)

$(NAME):    $(OBJS) $(HEADERS)
        $(CC) $(CFLAGS) $(OBJS) -o $(NAME) $(LDFLAGS)

$(LINK):    $(NAME)
        ln -sf $(NAME) $(LINK)

%.o:        %.c $(HEADERS)
        $(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@

clean:
        rm -f $(OBJS)

fclean:     clean
        rm -f $(NAME) $(LINK) test_malloc

re:         fclean all
test:       $(NAME) $(LINK)
        cc -o test_malloc tests/test.c -L. -lft_malloc -pthread
        LD_LIBRARY_PATH=. LD_PRELOAD=./$(NAME) ./test_malloc

Flags expliqués

-fPIC : Position Independent Code

Sans -fPIC, le code généré utilise des adresses absolues. Par exemple, mov rax, [g_malloc] compile en mov rax, [0x4040] — adresse absolue. Ça marche pour un exécutable (le loader charge toujours à la même adresse), mais pas pour une bibliothèque partagée qui peut être mappée à n'importe quelle adresse. Avec -fPIC, le code utilise des adresses relatives via la table GOT (Global Offset Table) : mov rax, [rip + got_offset]. Le loader remplit la GOT à l'adresse où la bibliothèque est effectivement chargée.

Si on oublie -fPIC, le linker refuse avec : "relocation R_X86_64_32 against `g_malloc' can not be used when making a shared object; recompile with -fPIC". Toujours inclure -fPIC dans CFLAGS pour une bibliothèque partagée.

HOSTTYPE : pourquoi cette variable ?

$HOSTTYPE est une variable d'environnement Bash qui contient l'architecture hôte (par exemple x86_64). Le sujet l'utilise pour nommer la bibliothèque afin que plusieurs versions (x86_64, arm64, etc.) puissent coexister sur la même machine. Sur certains systèmes, $HOSTTYPE peut être vide — le Makefile doit donc calculer une valeur de secours : $(shell uname -m)_$(shell uname -s) (par exemple x86_64_Linux).

Le lien symbolique

Pourquoi un lien symbolique libft_malloc.so → libft_malloc_$HOSTTYPE.so ? Parce que LD_PRELOAD=libft_malloc.so cherche littéralement libft_malloc.so. Si seul libft_malloc_x86_64_Linux.so existe, le preload échoue silencieusement — le programme utilise le malloc système sans qu'on sache qu'on teste pas notre code. Le lien symbolique assure que libft_malloc.so pointe toujours vers la bonne version.

Script run.sh pour tester avec LD_PRELOAD

Le sujet fournit un script run.sh qui précharge la bibliothèque dans n'importe quel programme, remplaçant le malloc système par le nôtre. Sur Linux :

#!/bin/sh
export LD_LIBRARY_PATH=.
export LD_PRELOAD=libft_malloc.so
$@

Usage : ./run.sh ./test_program args.... Le programme utilisera notre malloc au lieu de celui de la libc.

Comment ça marche ?

LD_PRELOAD est une variable d'environnement lue par le loader Linux (ld.so). Elle indique que la bibliothèque spécifiée doit être chargée avant la libc. Comme notre bibliothèque définit malloc, free, realloc avec les mêmes symboles que la libc, le linker dynamique résout les appels vers notre version (premier trouvé gagne). LD_LIBRARY_PATH=. indique au loader de chercher la bibliothèque dans le répertoire courant.

Règles du Makefile

Le sujet fournit 7 fichiers de test (test0.c à test6.c) qui couvrent les cas principaux. Nous avons ajouté un stress.c pour valider la robustesse en charge. Cette section présente le code de chaque test, ce qu'il vérifie, et le résultat attendu.

test0 : baseline sans malloc

Le test0 ne fait aucun malloc — c'est la baseline pour mesurer l'empreinte mémoire du programme vide. On compare ensuite test1 (qui fait 1 MB de malloc) à test0 pour compter les pages réellement allouées par notre malloc.

int    main(void)
{
        return (0);
}

Résultat attendu : exit 0, ~1268 KB RSS, ~81 minor page faults. C'est l'empreinte d'un programme C minimal (runtime CRT + libc chargée + notre .so préchargée).

test1 : 1 MB de malloc

Le test1 alloue 1024 × 1024 = 1 MB de mémoire en boucle, et remplit chaque allocation avec memset pour forcer les page faults. C'est ce test qui détermine la note principale du projet (page efficiency).

int    main(void)
{
 int      i;

        i = 0;
        while (i < 1024)
        {
         char     *p = malloc(1024);
                if (p) memset(p, 'A', 1024);
                i++;
        }
        return (0);
}

Résultat avec notre malloc : test1 génère ~348 minor page faults, contre ~81 pour test0. La différence (348 − 81 = ~267 pages) est le nombre de pages réellement allouées par notre malloc. Selon la grille d'évaluation, 255-272 pages = note 5/5 (excellent). Pourquoi ~267 pages ? Chaque allocation de 1024 bytes va en zone SMALL (131072 bytes = 32 pages). 1024 allocations / 124 blocs par zone ≈ 9 zones SMALL nécessaires = 9 × 32 = 288 pages théoriques, réduites à ~267 grâce à la lazy allocation (le noyau n'alloue les pages physiques qu'au premier write).

test2 : malloc + free

Le test2 fait la même chose que test1, mais libère chaque allocation après l'avoir remplie. Si notre free fonctionne, le nombre de pages doit être bien inférieur à test1 (idéalement proche de test0).

int    main(void)
{
 int      i;

        i = 0;
        while (i < 1024)
        {
         char     *p = malloc(1024);
                if (p) memset(p, 'A', 1024);
                free(p);   // libère tout de suite
                i++;
        }
        return (0);
}

Résultat : ~84-86 minor page faults (contre ~81 pour test0 et ~348 pour test1). La différence de ~3-5 pages avec test0 est due à la zone SMALL qui reste allouée (les frees marquent les blocs comme libres mais ne rendent pas la mémoire au système pour TINY/SMALL). C'est le comportement attendu. La fiche d'évaluation exige ≤ 3 pages de différence avec test0 pour la note maximale "quality of free" — notre résultat est à la limite, principalement à cause de la zone SMALL qui reste mappée.

test3 : realloc grow (avec buffer overflow latent)

Le test3 est le plus subtil du lot. Il alloue 4 bytes, copie une string plus longue (« Bonjour » = 8 bytes), puis fait un realloc pour grow à strlen(av[1]) + 1. Voici le code réel :

int    main(int ac, char **av)
{
 char     *s;

        s = malloc(4);
        if (ac > 1) strcpy(s, av[1]);   // overflow !
        s = realloc(s, strlen(av[1]) + 1);
        if (ac > 2) strcpy(s + strlen(av[1]), av[2]);
        write(1, s, strlen(s));
        write(1, "\n", 1);
        free(s);
        return (0);
}

Pourquoi ./test3 Bonjour affiche-t-il Bonj (4 caractères) et non Bonjour (7 caractères) ? Parce que le strcpy(s, "Bonjour") écrit 8 bytes (« Bonjour\0 ») dans une allocation de 4 bytes — c'est un buffer overflow. Le 5e byte écrase block->free, les bytes suivants écrasent block->next. Quand realloc appelle get_block_size(ptr), il lit block->size qui vaut toujours 4 (la taille originale, non corrompue par le overflow). Donc le copy_data ne copie que 4 bytes : « Bonj ».

test4 : realloc shrink + grow

Le test4 enchaîne shrink puis grow pour vérifier que le realloc gère bien les deux sens. C'est le vrai test du cas « shrink » (test3 faisait un grow).

int    main(void)
{
 char     *s;

        s = malloc(16);
        strcpy(s, "Hello");
        s = realloc(s, 4);    // shrink à 4
        write(1, s, 4);          // "Hell"
        write(1, "\n", 1);
        s = realloc(s, 1024);   // grow à 1024
        strcpy(s, "World");
        write(1, s, 5);          // "World"
        write(1, "\n", 1);
        free(s);
        return (0);
}

Sortie attendue : Hell World . Notre realloc : (1) shrink 16→4 retourne le même pointeur ; (2) grow 4→1024 fait malloc(1024) + copy 4 bytes + free l'ancien. Le "World" est bien copié.

test5 : error management

Le test5 vérifie le cas realloc(ptr, 0) qui doit libérer ptr et retourner NULL.

int    main(int ac, char **av)
{
 char     *s;

        s = NULL;
        if (ac > 1)
        {
                s = malloc(strlen(av[1]) + 1);
                if (s) strcpy(s, av[1]);
        }
        s = realloc(s, 0);   // libère s, retourne NULL
        if (s == NULL && ac > 1)
        {
                write(1, av[1], strlen(av[1]));   // "Bonjour"
                write(1, "\n", 1);
        }
        return (0);
}

Notre realloc : if (size == 0) { free(ptr); return (NULL); }. Donc realloc(s, 0) libère s et retourne NULL. La condition s == NULL est vraie, on affiche "Bonjour ".

test6 : show_alloc_mem

Le test6 alloue plusieurs blocs de tailles variées et appelle show_alloc_mem pour vérifier le format d'affichage.

int    main(void)
{
 char     *a;
 char     *b;
 char     *c;
 char     *d;

        a = malloc(10);
        b = malloc(100);
        c = malloc(5000);
        d = malloc(50);
        memset(a, 'A', 10);
        memset(b, 'B', 100);
        memset(c, 'C', 100);
        memset(d, 'D', 50);
        show_alloc_mem();
        write(1, "\n--- show_alloc_mem_ex ---\n", 29);
        show_alloc_mem_ex();
        return (0);
}

Sortie attendue (format sujet) :

TINY : 0x7fbe3bc86000
0x7fbe3bc86040 - 0x7fbe3bc8604a : 10 bytes
0x7fbe3bc8606a - 0x7fbe3bc860ce : 100 bytes
0x7fbe3bc860ee - 0x7fbe3bc86120 : 50 bytes
LARGE : 0x7fbe3bc84000
0x7fbe3bc84040 - 0x7fbe3bc853c8 : 5000 bytes
Total : 5160 bytes

Comment compter les pages

La fiche d'évaluation demande de compter les pages avec /usr/bin/time -v et la ligne "Minor (reclaiming a frame) page faults". La différence entre test1 et test0 donne le nombre de pages réellement allouées par notre malloc. Sur Linux, on peut aussi utiliser getrusage via un wrapper C :

#include <stdio.h>
#include <sys/resource.h>
#include <unistd.h>
#include <sys/wait.h>

int main(int argc, char **argv)
{
   struct rusage ru;
 pid_t pid = fork();
        if (pid == 0) {
                execvp(argv[1], argv + 1);
                _exit(127);
        }
 int status;
        wait4(pid, &status, 0, &ru);
        fprintf(stderr, "Maximum resident set size: %ld KB\n", ru.ru_maxrss);
        fprintf(stderr, "Minor page faults: %ld\n", ru.ru_minflt);
        fprintf(stderr, "Exit status: %d\n", WEXITSTATUS(status));
        return WEXITSTATUS(status);
}

Usage : ./run.sh /tmp/usage ./tests/test1. Le wrapper fork le programme, attend sa fin, et affiche les stats via getrusage.

Récapitulatif des tests

Audit complet réalisé selon la fiche d'évaluation officielle 42. Voici les résultats section par section, avec les scores obtenus.

Préliminaires

Compilation & export

Page efficiency (critère principal)

Le test1 demande 1024 × 1024 = 1 MB. La fiche d'évaluation note le nombre de pages utilisées au-dessus de la baseline test0 (par page reclaims via /usr/bin/time -v) :

Zones pré-allouées

Bonus

Cette section regroupe les pièges les plus courants du projet malloc, classés par ordre de fréquence. Chaque piège est illustré d'un exemple de bug et de sa correction.

1. Mutex non initialisé → crash aléatoire

Si on oublie d'initialiser le mutex (avec pthread_mutex_init ou PTHREAD_MUTEX_INITIALIZER), le premier appel à pthread_mutex_lock a un comportement indéfini. Sur Linux avec glibc, ça peut marcher par chance (le mutex est dans le BSS, zeroed par défaut, et un mutex zeroed est valide). Sur d'autres plateformes (Mac), ça crash systématiquement.

2. free(non-malloc ptr) → segfault

Si on oublie le test zone == NULL dans free, un free sur un pointeur étranger (stack, data segment, ou libc malloc) va écrire dans block->free = FREE à une adresse invalide → segfault. Le test find_zone(ptr) == NULL protège contre ça.

3. Off-by-one dans le calcul de zone

La vérification (char *)ptr > (char *)zone && (char *)ptr < (char *)zone + zone->size utilise des inégalités strictes. Un >= sur la borne inférieure accepterait ptr = zone (le header lui-même), ce qui corromprait la zone. Un <= sur la borne supérieure accepterait ptr = zone + zone->size (juste après la zone), ce qui lirait dans la zone suivante.

4. Oublier le -fPIC → relocation error

Sans -fPIC, le code généré utilise des adresses absolues. Quand on charge la .so via LD_PRELOAD, le loader refuse avec "relocation R_X86_64_32 against `g_malloc' can not be used when making a shared object". Toujours inclure -fPIC dans CFLAGS.

5. Pas de lien symbolique → LD_PRELOAD silently fails

LD_PRELOAD=libft_malloc.so cherche littéralement libft_malloc.so dans LD_LIBRARY_PATH. Si seul libft_malloc_x86_64_Linux.so existe, le preload échoue silencieusement (le programme utilise le malloc système). Toujours créer le lien symbolique dans le Makefile.

6. Norminette et règles 42

Le respect strict de la norme 42 (5 fonctions max par fichier, 25 lignes max par fonction, tabs pas spaces, headers 42 obligatoires, pas de for) est un critère éliminatoire : "No norm errors, Norminette is authoritative." La fiche d'évaluation dit explicitement que si un élément de la liste préliminaire n'est pas respecté, la défense s'arrête.

7. Le piège du test3 (undefined behavior)

Le test3 affiche Bonj et non Bonjour — ce n'est pas un comportement défini, mais un side-effect de l'overflow. Le test fait malloc(4) puis strcpy(s, "Bonjour") (8 bytes dans 4) — c'est un buffer overflow qui corromp block->free et block->next, mais pas block->size (qui est avant le payload). Quand realloc lit block->size, il trouve 4, donc copie 4 bytes → "Bonj". La fiche d'évaluation accepte "Bonj" comme réponse attendue car c'est ce que produisent la plupart des allocateurs 42, mais techniquement c'est de l'UB. Voir section 13 · test3 pour le détail.

8. Double free non détecté

Notre implémentation ne détecte pas les double-free. Si on appelle free(ptr) deux fois, la deuxième fois va marquer le bloc comme FREE (déjà fait), puis merger avec les voisins — ce qui peut corrompre la liste chaînée si le bloc a déjà été mergé. La glibc détecte ça et abort() avec un message "double free or corruption". Pour notre projet, ce n'est pas exigé, mais c'est un point à mentionner à la défense. Pour l'implémenter, on pourrait ajouter un flag MAGIC dans le t_block, vérifier qu'il est USED avant de le libérer, et le remplacer par MAGIC_FREED après.

9. mmap retourne MAP_FAILED, pas NULL

Une erreur courante : tester if (zone == NULL) après mmap. Mais mmap retourne MAP_FAILED ((void*)-1) en cas d'erreur, pas NULL. Le bon test est if (zone == MAP_FAILED). Si on teste NULL, on traite l'erreur comme un succès, et on essaie d'écrire dans l'adresse -1 → segfault.

10. Alignement des pointeurs

Le malloc de la libc garantit que le pointeur retourné est aligné sur 16 bytes (sur 64 bits). Notre implémentation ne le garantit pas explicitement — sizeof(t_block) = 32, donc le payload est aligné sur 32 bytes si la zone est alignée (ce qui est le cas avec mmap qui retourne des adresses alignées sur page). Mais si on changeait la structure pour avoir un header non multiple de 16, on pourrait casser des programmes qui supposent l'alignement (SSE, AVX).

11. Le piège du HOSTTYPE vide

Sur certains shells (zsh par défaut), $HOSTTYPE n'est pas défini. Si le Makefile ne gère pas ce cas, il produit libft_malloc_.so (avec un underscore vide) et le lien libft_malloc.so pointe vers ça. Ça compile, ça link, mais le test avec HOSTTYPE=Testing échoue car le Makefile ne recompile pas avec le nouvel HOSTTYPE (la règle make re supprime et recrée, mais avec le mauvais nom si la détection est cassée).

12. Compilation sans -pthread → mutex undefined

Si on oublie -pthread dans LDFLAGS, le linker ne trouve pas pthread_mutex_lock et échoue avec "undefined reference to `pthread_mutex_lock'". Sur certains systèmes, il faut aussi -lpthread explicite. -pthread est le flag moderne qui gère à la fois la compilation (define _REENTRANT) et le linkage.

Le projet passe la norminette 42 avec 0 erreurs. Cette section présente les règles appliquées et les choix structurels pour y parvenir.

$ norminette includes/ srcs/
malloc.h: OK!
show_alloc_mem_ex.c: OK!
calloc.c: OK!
ft_utils.c: OK!
free.c: OK!
realloc.c: OK!
debug.c: OK!
zone_helpers.c: OK!
show_alloc_mem.c: OK!
malloc.c: OK!
free_utils.c: OK!

# 0 erreurs. Seul un notice GLOBAL_VAR_DETECTED sur g_malloc,
# qui est autorisé par le sujet (1 globale pour les allocations).

Règles 42 appliquées

Headers 42

Tous les fichiers commencent par un header 42 standard avec rakrouna comme auteur et rakrouna@student.42.fr comme email. Le format est généré par un script Python mt_header.py pour garantir la cohérence.

/* ************************************************************************** */
/*                                                                            */
/*                                                        :::      ::::::::   */
/*   malloc.c                                           :+:      :+:    :+:   */
/*                                                    +:  +:+         +:+     */
/*   By: rakrouna <rakrouna@student.42.fr>          +#+  +:+       +#+        */
/*                                                +#+#+#+#+#+   +#+            */
/*   Created: 2026/07/03 17:27:14 by rakrouna          #+#    #+#             */
/*   Updated: 2026/07/04 10:00:00 by rakrouna         ###   ########.fr       */
/*                                                                            */
/* ************************************************************************** */

Stratégie de découpage

Pour respecter la règle des 5 fonctions par fichier, on a découpé le projet en 10 fichiers. La stratégie :

1. Identifier les fonctions qui ont un rôle cohérent (allocation, libération, affichage, debug)
2. Regrouper les fonctions liées dans un fichier (malloc.c pour les fonctions d'allocation)
3. Quand un fichier dépasse 5 fonctions, extraire les helpers dans un fichier séparé (zone_helpers.c, free_utils.c, ft_utils.c)
4. Les helpers non-static sont déclarés dans malloc.h pour être partagés
5. Vérifier avec norminette après chaque découpage

Notre malloc est fonctionnel et passe tous les tests, mais il est loin d'être optimal. Cette section compare notre implémentation aux allocateurs de production (glibc, jemalloc, tcmalloc) et suggère des optimisations possibles.

Comparaison avec la glibc

Le malloc de la glibc (ptmalloc2) est basé sur dlmalloc de Doug Lea, avec des améliorations pour le multi-thread. Il utilise des arenas multiples (un pool de mutex par thread) pour réduire la contention, des bins indexés par taille pour accélérer la recherche de bloc libre, et un top chunk qui s'étend via sbrk pour les petites allocations. Notre implémentation est environ 10× plus lente que la glibc en single-thread, et 100× plus lente en multi-thread à cause de la contention sur le mutex global.

Pourquoi notre malloc est plus lent

1. Mutex global — Tous les threads se contention sur un seul mutex. La glibc a une arena par thread (ou presque), donc la contention est faible.
2. Recherche linéaire — Pour chaque malloc, on parcourt tous les blocs d'une zone. La glibc indexe les blocs par taille (bins), donc O(1) pour trouver un bloc.
3. Pas de cache — Chaque malloc/free touche les listes chaînées. La glibc a des "fastbins" pour les petites allocations récemment libérées, qui sont réutilisées sans parcours.
4. Pas de trim — Les zones TINY/SMALL ne sont jamais rendues au système. La glibc fait un "trim" périodique qui rend les pages libres au noyau.
5. Alignement — On aligne sur 32 bytes (sizeof(t_block)), la glibc sur 16 bytes. On gaspille un peu plus par allocation.

Optimisations possibles

1. Bins par taille (best-fit)

Au lieu de parcourir tous les blocs, maintenir des listes séparées par taille (par exemple, une liste pour 16B, une pour 32B, une pour 64B, etc.). Pour un malloc(50), on va directement à la liste des 64B. C'est ce que fait la glibc avec ses "fastbins" pour les petites tailles.

2. Thread-local cache

Chaque thread a son propre cache de blocs libres récemment libérés. Pour un malloc, on essaie d'abord le cache local (pas de mutex), puis seulement si vide on prend le mutex global. C'est ce que fait jemalloc avec ses "tcache".

3. Arenas multiples

Au lieu d'un seul g_malloc, on en maintient plusieurs (typiquement 4× le nombre de CPUs). Chaque thread est associé à une arena (round-robin ou hash du TID). Réduit la contention.

4. Trim périodique

Quand une zone TINY/SMALL a beaucoup de blocs libres contigus (≥ 1 page), on peut munmap ces pages pour les rendre au système. La glibc fait ça dans malloc_trim.

5. Slab allocation

Pour les tailles très fréquentes (8, 16, 32 bytes), pré-allouer des slabs entiers de blocs de même taille. Pas de header par bloc (la taille est implicite), pas de split, free en O(1). C'est ce que fait le slab allocator de Linux kernel.

Pour aller encore plus loin

• Lire le code source de glibc malloc (~3000 lignes)
• Lire jemalloc (Jason Evans, utilisé par Facebook)
• Lire tcmalloc (Google, optimisé pour faible contention)
• Le papier "Scalable memory allocation using jemalloc" de Jason Evans
• Le papier "Reconsidering glibc malloc for vulnerable programs" sur les attaques par heap

Termes techniques utilisés dans ce guide, classés par ordre alphabétique.