---
title: "Partie 2 : Les langages comme C/C++ ou Zig permettent de contrôler la mémoire mais à quel prix ?"
description: "C évite le besoin d'avoir un garbage collector et donne un contrôle manuel de la mémoire, mais ouvre la porte à des bugs dangereux."
url: "https://mayorana.ch/fr/blog/c-low-level-cost-fr"
language: "fr"
date: "2025-08-08"
author: "Mohamed Bennekrouf"
tags:
- "rust"
- "c"
- "memory"
- "dangling-pointer"
- "undefined-behavior"
en_version: "https://mayorana.ch/en/blog/c-low-level-cost.md"
---
# Partie 2 : Les langages comme C/C++ ou Zig permettent de contrôler la mémoire mais à quel prix ?
Avec C, il n'y a pas de runtime, pas de GC.
```c
char* msg = malloc(100);
strcpy(msg, "hello");
free(msg);
printf("%s", msg); // ❌ Use after free
```
## Pièges courants
| Problème | Code | Risque |
|----------|------|--------|
| Use-after-free | `printf("%s", msg);` | Undefined behavior |
| Double free | `free(msg); free(msg);` | Heap corruption |
| Buffer overflow | `char buf[4]; strcpy(buf, "long");` | Memory corruption |
| Memory leak | `malloc(...)` sans `free` | Crashes lents |
## Modèle de mémoire Manuelle
Tu dois :
- Allouer la mémoire
- Tracker l'ownership
- La libérer manuellement
- Éviter d'accéder à la mémoire freed ou invalide
## Conséquences réelles
Voici quelques bugs connus.
### Heartbleed (OpenSSL)
```c
// Version simplifiée du bug
char* buffer = malloc(payload_length);
memcpy(buffer, payload, payload_length); // Pas de bounds check !
// L'attaquant pouvait lire au-delà du buffer
```
**Impact :** Plus de 500 000 serveurs ont exposé leurs clés privées et mots de passe.
### CVE-2021-44228 (Équivalent Log4Shell en C)
```c
char* user_input = get_user_data();
sprintf(log_buffer, "User: %s", user_input); // Buffer overflow possible
```
**Le Problème :** Pas de bounds checking automatique signifie que les attaquants peuvent :
- Crasher ton programme
- Exécuter du code arbitraire
- Voler des données sensibles
## Sécurité de la mémoire niveau statique (dans le code statique, avant l'exécution / runtime)
**Vulnérabilités de sécurité par catégorie :**
- **70%** des bugs sécurité Microsoft : problèmes de memory safety
- **65%** des vulnérabilités Chrome : memory corruption
- **~50%** des patches sécurité Android : liés à la mémoire
## Un poid pour le développeur
### Chaque allocation nécessite un tracking
```c
typedef struct {
char* data;
size_t size;
} Buffer;
Buffer* create_buffer(size_t size) {
Buffer* buf = malloc(sizeof(Buffer));
if (!buf) return NULL;
buf->data = malloc(size);
if (!buf->data) {
free(buf); // Il faut se rappeler de nettoyer !
return NULL;
}
buf->size = size;
return buf;
}
void destroy_buffer(Buffer* buf) {
if (buf) {
free(buf->data); // Il faut free dans le bon ordre
free(buf);
}
}
```
**Saturation mental :** Chaque fonction doit considérer :
- Qui possède ce pointer ?
- Quand doit-il être liberé ?
- Est-il encore valide ?
### Debugging des problèmes mémoire
```bash
$ valgrind ./my_program
==12345== Invalid read of size 4
==12345== at 0x40084B: main (test.c:10)
==12345== Address 0x5204044 is 0 bytes after a block of size 4 alloc'd
==12345== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
```
**Un des problèmes majeurs :** Les bugs sont découverts trop tard, au runtime, pas au moment de la compilation.
## Trade-off performance vs sécurité
### Caractéristiques performance de C
```c
// Zero overhead - accès mémoire direct
int sum = 0;
for (int i = 0; i < 1000000; i++) {
sum += array[i]; // Pas de bounds checking
}
```
**Vitesse :** ✅ Performance maximale
**Sécurité :** ❌ Une erreur = vulnérabilité de sécurité
### Contrôle de l'empreinte mémoire
```c
// Contrôle précis de l'emprunte mémoire
struct Point {
float x, y, z; // Exactement 12 bytes
} __attribute__((packed));
Point* points = malloc(1000 * sizeof(Point)); // Allocation prévisible
```
**Contrôle :** ✅ Contrôle complet de l'emprunte mémoire
**Risque :** ❌ Gestion manuelle des lifetimes
## Les outils aident, mais ne suffisent pas
### Static Analysis
```c
// clang-static-analyzer peut attraper certains problèmes
char* ptr = malloc(10);
free(ptr);
*ptr = 'x'; // ⚠️ Warning: use after free
```
### Runtime Detection
```c
// AddressSanitizer (ASan) attrape les bugs au runtime
$ gcc -fsanitize=address program.c
$ ./a.out
=================================================================
==12345==ERROR: AddressSanitizer: heap-use-after-free
```
### La Limitation
- **Outils static :** Ratent les cas complexes, faux positifs
- **Outils runtime :** Ne détectent les bugs qui s'exécutent que pendant les tests
- **Code review :** Erreur humaine, chronophage
## Pourquoi C est toujours utilisé malgré les risques
### Exigences de programmation système
- **Systèmes d'exploitation :** Besoin d'accès direct au hardware
- **Systèmes embarqués :** Contraintes mémoire, pas de place pour un runtime
- **Code critique en performance :** Chaque nanoseconde compte
### Legacy et écosystème
- **Bases de code massives :** Décennies de code C en production
- **Écosystème de librairies :** La plupart des librairies système écrites en C
- **Connaissance développeur :** Générations de programmeurs C
## Le problème Fondamental
C te donne deux mauvais choix :
**Option 1 : Gestion manuelle de la mémoire**
```c
char* data = malloc(size);
// ... logique complexe ...
if (error) {
free(data); // Il faut se souvenir du cleanup dans TOUS les chemins
return -1;
}
// ... plus de logique ...
free(data); // Facile d'oublier ou de double-free
```
**Option 2 : [Garbage collector](https://mayorana.ch/fr/blog/why-garbage-collector-fr)**
- Ajouter une librairie GC comme Boehm GC
- Perdre la prévisibilité des performances
- Toujours possible d'avoir des fuites mémoires
## Points clés
✅ **Performance prévisible - pas de pauses GC**
✅ **Contrôle complet de l'emprunte mémoire**
✅ **Overhead runtime minimal**
❌ **Unsafe par défaut - une erreur = vulnérabilité**
❌ **Responsabilité élevé pour les développeurs**
❌ **La plupart des bugs sécurité viennent des problèmes mémoire**
❌ **Les outils détectent les bugs après qu'ils soient écrits, pas avant**
---
**Le Défi :** Nous voulons la performance de C/C++ sans ses inconvénients.
**La Question :** Et si le compilateur pouvait prévenir les bugs mémoire au moment de la compilation ?
**Suivant :** "Voir la partie 3 de cette article"