Bac à sable C

Bac à sable C en ligne — compilez et exécutez du C avec GCC 10.2 dans votre navigateur. Choisissez C89/C99/C11/C17, activez -Werror, ajoutez flags (-Wall -O2 -lm) et stdin.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

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 3 secondes d'exécution (de sorte que du code non fiable ne peut rien endommager, et les benchmarks lourds peuvent être coupés). 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. Un sélecteur de Standard C (C89/ANSI, C99, C11, C17) et une option -Werror en un clic vous permettent de vérifier la portabilité et la conformité, tandis que les arguments de compilateur personnalisés (-Wall, -Wextra, -O0..-O3, -lm, -lpthread) vous permettent d'expérimenter avec les niveaux d'optimisation 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`.

Bac à sable C — Bac à sable C en ligne — compilez et exécutez du C avec GCC 10.2 dans votre navigateur. Choisissez C89/C99/C11/C17, acti — **Bac à sable C**

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.

Quel standard C choisir (C89, C99, C11, C17) ?

Utilisez le menu 'Standard C' pour compiler contre une version précise du langage — il règle -std= pour vous. Choisissez selon la cible, pas selon 'le plus récent est le meilleur' :

- C89 (ANSI C) : le plus portable. De nombreux toolchains embarqués et bases de code héritées l'exigent. C89 interdit les commentaires // de ligne, les déclarations après instructions et les variables à portée de boucle for (for (int i...) est une erreur). Sélectionner C89 est le moyen le plus rapide de vérifier si votre code est réellement portable.

- C99 : ajoute les commentaires //, les déclarations mélangées, les initialiseurs désignés, les tableaux de longueur variable, long long, stdint.h et bool via stdbool.h. Une base raisonnable pour du code moderne.

- C11 : ajoute _Static_assert, les structs/unions anonymes, _Generic et les optionnels <threads.h>/<stdatomic.h> pour la concurrence portable. Par défaut ici.

- C17 (alias C18) : aucune nouveauté — c'est C11 avec corrections de défauts. Choisissez-le pour la sémantique C11 avec les derniers correctifs.

Astuce : activez -Werror et compilez sous C89 pour transformer chaque construction non portable en erreur fatale.

Que change -O0 par rapport à -O3, et pourquoi la sortie peut-elle différer ?

Les flags -O contrôlent l'optimisation, qui peut changer radicalement le code généré (et parfois révéler des bugs) :

- -O0 (par défaut si vous ne réglez rien) : aucune optimisation. Compilation la plus rapide, débogage le plus facile, les variables restent en mémoire. Idéal pendant le développement.

- -O1 / -O2 : de plus en plus agressives — inlining, élimination de code mort, optimisations de boucle, allocation de registres. -O2 est le réglage habituel de release.

- -O3 : ajoute inlining agressif et vectorisation. Binaires plus gros ; pas toujours plus rapide.

- -Os / -Ofast : optimisent pour la taille / pour la vitesse pure (en relâchant les maths IEEE). Évitez -Ofast sauf si vous comprenez les compromis en virgule flottante.

Pourquoi les résultats peuvent différer selon les niveaux : si votre programme a un COMPORTEMENT INDÉFINI (débordement signé, lecture de mémoire non initialisée, accès hors limites, violations de strict-aliasing), l'optimiseur peut supposer que cela n'arrive jamais et supprimer ou réordonner le code en conséquence. Du code qui 'marche' en -O0 mais casse en -O2 cache presque toujours un comportement indéfini — compilez avec -Wall -Wextra et essayez -fsanitize=undefined en local pour le détecter.

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.