[Archive — École 42] Projet Libft + Configuration de la norminette sur VSCode

Mahaut Latinis
5 min readSep 28, 2023

--

💡Cette note a été rédigée dans le but d’aider mes camarades à la compréhension du sujet “libft” (école 42).

La libft est le premier projet du “tronc commun” de l’école 42. On y retrouve différentes notions déjà vues lors du concours d’entrée (aussi appelé “la piscine”).

Il vous sera demandé de re coder une grande partie des fonctions de la libc (bibliothèque standard du C), en respectant “la norme” (= ensemble de conventions assurant la lisibilité/propreté de votre code).

  • Si vous voulez vous essayez au respect de la norme (qui est en quelque sorte un ancêtre de linter), vous pouvez l’installer (suivre README ici : https://github.com/42School/norminette) et lancer la commande suivante depuis votre “working directory” (dossier courant, où doivent se trouver vos fichiers .c et .h) :
norminette

Cette commande vous indique les différentes règles non respectées (ou à contrario si le fichier est bien propre “OK!”) sur chacun des fichiers (exemple: ft_strnstr.c) et les lignes concernées.

Vous disposez d’une extension VSCode (dédiée à la Version 3) pour observer facilement les erreurs de norme (plutôt que de tout faire en ligne de commande). Je vous recommande par ailleurs de prendre rapidement en main VSCode plutôt que de rester sur l’éditeur Vim utilisé durant le concours (vous gagnerez du temps grâce aux extensions et raccourcis!).

L’équipe pédagogique de l’école 42 a tendance à faire évoluer ses conventions, c’est pourquoi vous verrez que certains projets validés par d’anciens élèves nécessitent d’éventuelles corrections.

Pensez à bien modifier votre fichier settings.json (settings VSCode) pour que l’extension soit bien configurée.

Lien vers mon repository Github: https://github.com/mahautlatinis/libft

Comprendre la bibliothèque standard C

Les fonctions de la bibliothèque standard permettent principalement l’allocation (mémoire) et la manipulation de chaînes de caractères (“strings”) (ou autres types de données) et la gestion d’entrées / sorties (écriture dans stdin, stdout, stderr).

Notez que le C est un language de programmation créé dans les années 70 par les fameux “Laboratoires Bell”. Il a été utilisé pour “réécrire” Unix qui n’est autre que le système d’exploitation (Operating System) à l’origine des OS les plus utilisés au monde de nos jours: GNU/Linux, iOS, macOS.

Unix repose sur un “interpréteur de commandes” (aussi appelé shell), accessible depuis un terminal, qui permet d’exécuter différents programmes (execs et builtins). Il vous permet de faire, via “la ligne de commande”, tout ce que vous avez l’habitude de faire via “l’interface graphique” (créer un dossier, éditer un fichier, déplacer, renommer, chercher, afficher…). Vous aurez, plus tard dans votre cursus, à écrire votre propre (mini) shell en respectant le comportement de “bash”.

Pour l’heure, il vous faudra simplement réécrire certaines fonctions et appréhender la notion de bibliothèque statique en C.

Bibliothèque statique en C

Une fois que vous aurez reproduit le comportements des fonctions de la bibliothèque standard (dans vos fichiers .c) et défini les en-têtes (dans votre fichier .h), il vous faudrait écrire votre Makefile, qui permettra la compilation de vos fichiers, mais surtout la création d’une librairie statique (.a). Cette librairie pourra être réutilisée dans vos futurs projets.

Plutôt que de copier coller tous vos fichiers .c dans vos futurs projets (pour les réutiliser), vous pourrez simplement utiliser votre bibliothèque statique — accompagnée de votre fichier d’en-tête).

La librairie sera générée via les étapes suivantes : (exemple avec un seul fichier)

# génération du fichier object 
gcc -c ft_isalpha.c -o ft_isalpha.o

# création de la librairie statique en utilisant le fichier object
ar -rc libft.a ft_isalpha.o

# Attention le nom doit obligatoirement commencer par "lib"

Voici un exemple de “main” (nécessaire pour obtenir un fichier a.out exécutable) qui vous permettra d’utiliser votre librairie.

Notez que vous devrez inclure dans votre commande pour compiler les options nécessaires pour spécifier l’utilisation de votre librairie.

# Ne marchera pas 
gcc main.c

# Marchera
gcc -L. -lft main.c

# -L. indique que la librairie à utiliser se trouve dans le dossier courant
# -lft indique le nom de la librairie (préfixer par "l" et non par "lib".)

# les étudiants 42 penseront à ajouter les flags -Wall -Wextra -Werror notamment

Cette dernière compilation sera plus optimisée que de (re) générer les .o (les .o sont indexés par la commandes ar -rc).

Pour vous assurer que votre sujet est bien réalisé, je vous invite de plus à chercher des “testeurs” (disponibles sur Github) afin de vérifier que vos fonctions reproduisent bien les fonctionnements attendus.

Ils réalisent une batterie de tests sur vos fonctions (en comparant les résultats de vos fonctions avec ceux des les fonctions standard) et vous garantiront que le projet pourra obtenir une note suffisante être validé.

Ici, vous pouvez voir un exemple comparaison (utilisez les mêmes arguments, contrairement à cette coquille ‘a’ et ‘A’) que vous pouvez faire vous-même.

Exemple de testeur (déprécié) :

Par convention, les développeurs “rangent” les fichiers d’en-tête (.h) dans un dossier “include” et les bibliothèques (.a) dans un dossier “lib”, mais cela n’est pas demandé dans le sujet.

Vous pouvez utiliser les chevrons plutôt que les quotes (“ ”) pour importer votre fichier d’en-têtes dans la mesure où vous allez spécifier où il se trouve à la compilation.

À noter : vous n’êtes pas obligés de “coller” le “path” et le nom de la lib aux flags -L et -l

gcc -I ./include -L ./lib -l ft main.c

# Pareil
gcc -I ./include -L./lib -lft main.c

# Pareil
gcc -I include -L lib -l ft main.c

--

--

Mahaut Latinis
Mahaut Latinis

No responses yet