Bac à sable C
Bac à sable C en ligne — compilez et exécutez du C11 via GCC 10.2 dans votre navigateur. Flags personnalisés, support stdin, 6 exemples. Sans installation.
Bac à sable C - Compiler et exécuter du code C en ligne
Le C est la lingua franca de la programmation système — le noyau Linux, les runtimes Python et Node.js, chaque firmware embarqué, chaque moteur de base de données, chaque portefeuille de cryptomonnaie, et environ la moitié des interpréteurs de langage 'de haut niveau' sont écrits en C. Pourtant, configurer une chaîne d'outils C en local (installer GCC/Clang, configurer le PATH, apprendre les bases du Makefile) est le premier mur que rencontre tout nouveau programmeur. Ce bac à sable supprime ce mur : collez un snippet, appuyez sur Exécuter, et votre code est compilé et exécuté contre GCC 10.2.0 avec support complet du standard C11 en moins d'une seconde. L'exécution se fait côté serveur via l'API Piston open-source (engineer-man/piston sur GitHub) dans un container Docker isolé sans accès réseau et avec une limite stricte de 10 secondes d'exécution, de sorte que du code non fiable ne peut rien endommager. Vous obtenez le stdout du programme, tous les avertissements/erreurs de compilation avec numéros de ligne, le temps d'exécution et le code de sortie. Les arguments de compilateur personnalisés (-Wall, -Wextra, -O0..-O3, -std=c89..c11, -lm, -lpthread) vous permettent d'expérimenter avec les niveaux d'optimisation, les standards de langage et l'édition de liens de bibliothèques. Le champ stdin alimente l'entrée standard pour les programmes basés sur scanf/getchar/fgets sans les réécrire. Six exemples de démarrage catégorisés — Hello World, boucle for, définition de fonction, itération de tableau, déréférencement de pointeur, utilisation de struct — couvrent la syntaxe que vous verriez en première semaine de tout cours de C.
Qu'est-ce que le bac à sable C ?
C'est un compilateur C en ligne qui fonctionne via votre navigateur. Basé sur Piston + GCC, il offre :
- Compilation et exécution instantanées
- Support de la bibliothèque standard
- Flags personnalisés côté compilateur
- Entrée standard (stdin)
- Messages d'erreur détaillés
- Exemples de code pour progresser
Parfait pour étudiants, développeurs et makers.
Comment l'utiliser ?
Procédure :
1. Écrivez ou collez votre code
2. Ajoutez des arguments (ex.: -Wall -O2) si besoin
3. Fournissez l'entrée stdin le cas échéant
4. Cliquez sur "Exécuter le code"
5. Analysez la sortie ou les erreurs
6. Chargez les exemples fournis pour réviser la base C
Vous pouvez aussi télécharger votre fichier .c pour le conserver.
Quelles fonctionnalités C sont supportées ?
Le bac à sable gère :
- Toutes les fonctionnalités C11
- Bibliothèque standard (stdio.h, stdlib.h, string.h, math.h...)
- Allocation dynamique (malloc, calloc, free)
- Entrée/sortie fichiers
- Pointeurs et arithmétique associée
- Structures et unions
- Tableaux et chaînes
- Pointeurs de fonctions
- Directives du préprocesseur
Compilateur : GCC 10.2.0 configuré pour C11.
Puis-je ajouter des flags compilateur ?
Oui, via le champ "Arguments du compilateur". Exemples :
- `-Wall` : avertissements complets
- `-Wextra` : avertissements supplémentaires
- `-O2` : optimisation niveau 2
- `-std=c11` : imposer la norme C11
- `-lm` : lier la bibliothèque math
- `-g` : ajouter les symboles de debug
Combinez-les selon vos besoins.

Comment utiliser stdin ?
Si votre programme emploie scanf(), gets(), fgets() ou autres fonctions d'entrée, ajoutez les données dans le champ "Entrée standard".
Exemple :
```c
#include <stdio.h>
int main() {
int num;
scanf("%d", &num);
printf("You entered: %d\n", num);
return 0;
}
```
Dans le champ stdin, tapez `42`. L'application lira cette valeur et affichera `You entered: 42`.
Pourquoi mon programme avec malloc/free semble-t-il fuir de la mémoire ?
Probablement qu'il ne fuit pas — mais le bac à sable ne peut pas le confirmer car Valgrind n'est pas disponible côté serveur. L'illusion d'une fuite mémoire dans cet environnement vient généralement d'une de trois choses. (1) Vous avez alloué de la mémoire et oublié free() avant que le programme se termine — strictement parlant, ce n'est pas une fuite, puisque l'OS récupère toute la mémoire du processus à la sortie, mais c'est tout de même un bug qui aurait son importance dans du code à longue durée de vie. (2) Vous confondez 'mémoire heap utilisée' avec 'mémoire fuie' : allouer un tableau d'un million d'int utilise ~4 Mo légitimement. (3) Votre free() est dans un chemin de code inaccessible — par exemple après un return précoce ou dans une branche if qui ne s'est pas exécutée. Pour vérifier hors ligne, installez GCC plus Valgrind localement et exécutez 'valgrind --leak-check=full ./votreprogramme' — Valgrind rapporte chaque malloc sans free correspondant avec la ligne source exacte de l'allocation. Les compilateurs modernes supportent aussi AddressSanitizer ('gcc -fsanitize=address') qui attrape les fuites au runtime avec beaucoup moins de surcharge que Valgrind.
Pourquoi mon code plante-t-il avec 'Segmentation fault' ?
Segfault signifie que votre programme a tenté d'accéder à une adresse mémoire qu'il ne possède pas. Les cinq causes les plus courantes en C débutant :
(1) Déréférencer un pointeur NULL : int *p = NULL; *p = 5; — crash. Vérifiez toujours les pointeurs avant de les déréférencer.
(2) Déréférencer un pointeur NON INITIALISÉ : int *p; *p = 5; — p contient des données aléatoires de la pile qui ne sont presque certainement pas une adresse valide.
(3) Buffer overflow : char buf[10]; strcpy(buf, "cette chaîne est beaucoup trop longue"); — écrit au-delà de la fin du tableau dans la mémoire de pile adjacente.
(4) Use-after-free : int *p = malloc(4); free(p); *p = 5; — p détient toujours l'ancienne adresse mais la mémoire ne vous appartient plus.
(5) Stack overflow par récursion infinie : int f(int n) { return f(n+1); } — main appelle f, f appelle f, finalement la pile d'appels atteint sa taille limite.
Le bac à sable affiche 'Segmentation fault (core dumped)' et un code de sortie 139 (128+SIGSEGV) quand cela arrive. Compilez avec -g et utilisez un débogueur local (gdb) ou AddressSanitizer pour identifier la ligne exacte.
Mon code est-il sécurisé ?
Confidentialité :
- Les sources sont envoyées à l'API Piston (emkc.org) uniquement pour compilation
- Piston est open-source et communautaire
- Le code n'est ni logué ni archivé
- L'exécution se déroule dans des conteneurs isolés
- Aucun accès à votre machine locale
Pour un contrôle total, il est possible d'auto-héberger Piston avec Docker.
Fonctionnalités clés
- Compiler du C en ligne via GCC
- Sans installation ni inscription
- Compilation et exécution rapides
- Support complet du standard C11
- Flags et arguments personnalisés
- Support de l'entrée standard (stdin)
- Messages d'erreur précis avec n° de ligne
- Exemples pédagogiques intégrés
- Téléchargement du code en .c
- Mesure du temps d'exécution
- Mode sombre
- Interface responsive pensée mobile
- Service gratuit propulsé par Piston
- Projet ouvert et soutenu par la communauté
