Égalité en C : 7 pièges à éviter en entretien

Maîtrisez l’égalité en C avec 7 pièges fréquents en entretien : =, ==, chaînes, pointeurs, flottants et boucles. Lisez pour éviter les erreurs.

La plupart des candidats qui bloquent sur les questions avec le signe égal lors d’entretiens C connaissent déjà les symboles. Le problème pour comprendre l’égalité en C n’est pas un problème de vocabulaire — c’est que personne ne leur a expliqué où le langage s’écarte de ce qu’ils attendraient intuitivement, et les intervieweurs savent exactement quelles trois ou quatre questions vont révéler cette lacune. Ce guide traite directement de ces sept pièges, avec des exemples concrets que vous pourrez analyser à voix haute sous pression.

== vs = : l’erreur qui intéresse vraiment les intervieweurs

La faute de frappe qui n’en est pas vraiment une

Écrire `=` au lieu de `==` dans une condition n’est pas une simple faute de frappe. Cela révèle que le candidat n’a pas encore bien distingué, dans son modèle mental, deux opérations différentes : l’une qui stocke une valeur et l’autre qui teste une relation. En C, `=` est l’opérateur d’affectation — il place une valeur dans une variable puis s’évalue à cette valeur. `==` est l’opérateur d’égalité — il vérifie si deux opérandes sont égaux et s’évalue à 1 ou 0. Ce sont fondamentalement deux rôles différents, et les intervieweurs posent d’abord cette question parce qu’elle leur indique si le candidat raisonne en termes de modification d’état ou d’inspection de l’état.

Si cette erreur survit dans du code réel, c’est parce que la grammaire de C autorise une affectation à l’intérieur d’une expression conditionnelle. Le compilateur ne rejette pas `if (x = 5)` — il le compile et l’exécute. De nombreux compilateurs, dont GCC, émettront un avertissement du type `warning: suggest parentheses around assignment used as truth value`, mais uniquement si les avertissements sont activés. Cet avertissement est le seul filet de sécurité.

Ce que cela donne en pratique

Le premier bloc `if` s’exécute toujours, quelle que soit la valeur initiale de `x`. L’affectation modifie l’état du programme puis la condition évalue la valeur affectée, et non la valeur d’origine. Un candidat qui avait écrit cela dans un exercice à rendre m’a un jour dit qu’il n’avait repéré l’erreur que parce que GCC l’avait signalée avec `-Wall`. Sans cette option, le programme s’exécutait, affichait quelque chose et semblait correct — jusqu’à ce qu’il vérifie ce que contenait `x` ensuite.

La documentation des avertissements de GCC couvre `-Wparentheses`, qui cible précisément ce motif. Activer `-Wall` pendant l’entraînement n’est pas facultatif.

Pourquoi les opérateurs de comparaison en C renvoient 1 ou 0, et non true ou false

Le modèle de vérité réellement utilisé par C

Les opérateurs de comparaison en C ne renvoient pas par défaut un type booléen — ils renvoient un entier. Plus précisément, une comparaison vraie s’évalue à `1` et une comparaison fausse à `0`. C99 a introduit `_Bool` et l’en-tête `<stdbool.h>`, qui vous donne `true` et `false` sous forme de macros, mais les valeurs sous-jacentes restent `1` et `0`. Si vous écrivez du C89 ou si vous n’incluez simplement pas `<stdbool.h>`, le mot-clé `true` n’existe pas. Le langage considère tout entier non nul comme vrai dans un contexte conditionnel, et zéro comme faux.

C’est important en entretien, car un candidat qui dit « la condition renvoie true » sans savoir ce que cela signifie en termes C donne l’impression d’importer des hypothèses de Python ou de Java. La réponse précise — « cela s’évalue à 1 ou 0, et l’instruction `if` traite toute valeur non nulle comme condition de branchement » — signale un niveau de compréhension différent.

Ce que cela donne en pratique

Un candidat qui a testé cela pendant sa préparation m’a dit un jour qu’il s’attendait à voir `true` affiché pour `result`. Quand il a vu `1`, il a supposé qu’il y avait un problème. Il n’y avait aucun problème — c’est exactement ainsi que fonctionne C. Le `1` est transmis au `if` comme entier non nul, la branche est exécutée, et le langage ne produit jamais de représentation textuelle de la vérité tout seul. La référence C sur cppreference.com confirme que les opérateurs relationnels et d’égalité renvoient des valeurs `int` de 0 ou 1.

Utilisez les six opérateurs de comparaison sans deviner

Toute la famille, pas seulement == et !=

L’opérateur d’égalité en C est `==`, mais il appartient à une famille plus large de six opérateurs de comparaison qui partagent tous le même comportement de retour : ils renvoient 1 lorsque la condition est vraie et 0 lorsqu’elle ne l’est pas. Les considérer comme une famille — plutôt que de les mémoriser isolément — facilite leur manipulation sous pression. Les six opérateurs sont : `==` (égal), `!=` (différent), `<` (strictement inférieur), `>` (strictement supérieur), `<=` (inférieur ou égal) et `>=` (supérieur ou égal).

Ce que cela donne en pratique

C’est le genre de mémo compact qui a sa place sur une page de notes de préparation. Chaque ligne exprime une idée complète, et le résultat découle directement de la définition de l’opérateur. La page cppreference sur les opérateurs de comparaison regroupe les opérateurs relationnels et d’égalité et confirme ce comportement pour les six.

La seule chose vraiment utile à mémoriser : `<=` et `>=` sont des opérateurs à deux caractères, et l’ordre compte — `=<` n’est pas du C valide. C’est une erreur réelle que des candidats commettent lorsqu’ils écrivent vite.

Arrêtez d’écrire des comparaisons qui se cassent dans les if et les boucles

Pourquoi les conditions révèlent les erreurs

Une expression de comparaison isolée qui donne la mauvaise valeur est sans gravité. La même erreur dans un `if` ou dans la condition d’une boucle devient un bug de flux de contrôle — elle change les branches exécutées et le nombre d’itérations d’une boucle. C’est pour cela que les intervieweurs s’intéressent aux opérateurs de comparaison en C dans le contexte du contrôle de flux, et pas seulement comme expressions autonomes. Un candidat qui comprend l’opérateur mais choisit le mauvais dans une condition a un bug qui ne plantera pas, ne lèvera pas d’exception et produira une sortie qui semblera plausible jusqu’à ce que quelqu’un vérifie la logique de près.

Ce que cela donne en pratique

Pendant sa préparation à un entretien, un candidat a écrit la seconde version en essayant de tester si `i` avait atteint 5. La boucle ne s’arrêtait jamais. L’affectation `i = 5` s’évalue à 5 à chaque passage dans la condition, ce qui est toujours non nul, donc la boucle tourne indéfiniment. Le fait que le compilateur considère l’affectation dans une condition comme une expression valide rend ce code survivable tout en restant compilé proprement.

La priorité des opérateurs est l’endroit où = et == commencent à provoquer de vrais bugs

Le bug qui semble correct jusqu’à ce qu’on le relise

La distinction entre `==` et `=` en C devient plus dangereuse lorsque les deux opérateurs apparaissent dans la même expression. La priorité des opérateurs en C n’est pas toujours intuitive, et une ligne qui ressemble à une comparaison peut devenir silencieusement une affectation selon la façon dont le compilateur l’analyse. L’opérateur d’affectation a une priorité inférieure à la plupart des opérateurs de comparaison, mais cet ordre ne vous aide que si vous connaissez la table de priorité. La plupart des débutants ne l’ont pas en tête — ils lisent de gauche à droite et supposent que l’expression fait ce qu’elle semble faire.

Le vrai piège est une expression comme `if (result = a == b)`. À l’œil, on lit cela comme « affecter le résultat de la comparaison de a et b », ce qui est effectivement ce que cela fait — mais seulement parce que `==` a une priorité supérieure à `=`. Inversez les opérateurs et le sens change complètement.

Ce que cela donne en pratique

GCC produit `warning: suggest parentheses around comparison in operand of '='` sur la première version. Cet avertissement est utile. La documentation des options d’avertissement de GCC explique comment `-Wparentheses` détecte exactement ce motif. En pratique, la règle sûre est la suivante : si vous avez besoin des deux opérateurs dans une même expression, utilisez des parenthèses pour expliciter l’ordre, au lieu de compter sur la priorité pour faire correctement le travail en silence.

Les chaînes sont l’endroit où == cesse de fonctionner comme les gens l’imaginent

Pourquoi deux chaînes identiques ne sont pas la même chose

La comparaison de chaînes en C est le piège qui surprend les candidats qui ont appris à comparer des chaînes avec `==` en Python, Java ou JavaScript. En C, une chaîne est un tableau de caractères stocké quelque part en mémoire, et une variable de chaîne ou un littéral est représenté par un pointeur vers le premier caractère de ce tableau. Lorsque vous écrivez `str1 == str2`, vous ne comparez pas le contenu textuel — vous comparez deux adresses mémoire. Deux chaînes au contenu identique mais stockées à des emplacements différents ne seront pas égales avec `==`.

Ce n’est ni une bizarrerie ni un bug. C’est une conséquence directe de la manière dont C représente les chaînes : comme des pointeurs `char *`, et non comme des objets de premier rang dotés d’une sémantique de comparaison intégrée. Si vous comprenez cela, le besoin de `strcmp` devient évident plutôt qu’arbitraire.

Ce que cela donne en pratique

Le résultat de `==` dépend de l’implémentation, car certains compilateurs mettent en commun les littéraux de chaîne (ils les stockent à la même adresse), donc `s1 == s2` peut par hasard renvoyer 1. Cela aggrave le bug : il passe avec un compilateur, puis échoue avec un autre. Un candidat qui a passé un après-midi à essayer de comparer des littéraux de chaîne avec `==` avant de découvrir `strcmp` a décrit cela comme « les trente minutes les plus déroutantes de ma préparation C » — parce que le code fonctionnait sur sa machine et échouait dans le correcteur. La page de manuel Linux pour strcmp documente l’approche correcte : `strcmp` renvoie 0 pour des chaînes égales, une valeur négative si la première est lexicographiquement inférieure, et une valeur positive si elle est supérieure.

L’égalité des pointeurs n’est pas l’égalité des valeurs

La question d’adresse que les intervieweurs vous posent réellement

La comparaison de pointeurs en C avec `==` vérifie si deux pointeurs contiennent la même adresse — s’ils pointent vers le même emplacement mémoire. Elle ne vérifie pas si les valeurs stockées à ces adresses sont égales. Les intervieweurs posent cette question parce que les candidats confondent souvent les deux : ils disent « je vérifie s’ils sont égaux » sans préciser en quel sens. La réponse qui impressionne est celle qui nomme immédiatement la distinction.

Ce que cela donne en pratique

Lors d’une séance de débogage, un candidat vérifiait si deux nœuds d’une liste chaînée contenaient la même donnée. Il a écrit `if (node1 == node2)` et s’est demandé pourquoi la branche ne s’exécutait jamais alors que les valeurs correspondaient. La comparaison de pointeurs était techniquement correcte — elle déterminait à juste titre que `node1` et `node2` étaient deux objets différents. Mais l’objectif réel était `node1 == node2`, c’est-à-dire comparer les valeurs stockées. La différence tient à un caractère (`*`) et à une question sémantique entièrement différente.

L’égalité en flottants est le piège qui semble évident jusqu’au moment où il ne l’est plus

Pourquoi == est le mauvais outil pour la plupart des comparaisons de flottants

Les nombres à virgule flottante en C sont stockés en binaire avec une précision finie. La plupart des fractions décimales — y compris des valeurs simples comme 0,1 — ne peuvent pas être représentées exactement en virgule flottante binaire. Lorsque vous faites des calculs sur des flottants, le résultat accumule des erreurs d’arrondi au niveau du matériel. Deux valeurs qui devraient être mathématiquement égales diffèrent souvent d’une très petite quantité dans leur représentation binaire, donc `==` renvoie 0 même si les valeurs semblent identiques à l’affichage.

Ce n’est pas un problème spécifique à C — c’est une conséquence de la représentation flottante IEEE 754, la norme qui régit l’arithmétique flottante dans presque tous les langages et processeurs modernes. C l’expose directement parce qu’il n’abstrait pas le matériel.

Ce que cela donne en pratique

La bonne approche pour comparer des flottants est un test de tolérance :

Un candidat qui construisait une calculatrice simple pendant sa préparation a passé une heure à déboguer un cas de test où `0.1 + 0.2 == 0.3` renvoyait faux. Les valeurs s’affichaient de manière identique avec deux décimales. Ce n’est qu’en augmentant la précision d’affichage que la différence d’arrondi est devenue visible. Les intervieweurs apprécient cette réponse parce qu’elle montre que le candidat comprend le matériel, pas seulement la syntaxe.

Comment Verve AI peut vous aider à préparer votre entretien sur l’égalité en C

Le problème structurel que cet article a mis en évidence n’est pas que ces sept pièges soient obscurs — c’est que les connaître sur le papier et les expliquer clairement sous un questionnement en direct sont deux compétences différentes. Lorsqu’un intervieweur vous demande « pourquoi ne peut-on pas utiliser == pour les chaînes en C ? », vous devez fournir une réponse claire et assurée en temps réel, et non une réponse correcte mais hésitante. Cela demande de l’entraînement dans des conditions réalistes, pas une simple relecture de notes.

Verve AI Interview Copilot est conçu précisément pour combler cet écart. Il écoute en temps réel vos réponses orales et réagit à ce que vous avez réellement dit — pas à une invite prédéfinie — afin que vous puissiez vous entraîner aux questions de suivi qui piègent le plus souvent les candidats. Supposons que vous expliquiez correctement mais vaguement la distinction entre `==` et `=`. Verve AI Interview Copilot peut vous relancer avec « que fait exactement le compilateur avec cette expression ? » et vous obliger à être plus précis. Ce type de pression dynamique est ce qui distingue les candidats qui ont mémorisé le sujet de ceux qui le comprennent. Verve AI Interview Copilot reste invisible pendant les sessions en direct, ce qui vous permet de l’utiliser jusqu’au moment de votre véritable entretien. Si vous voulez cesser de paraître hésitant lorsque la question du signe égal arrive, le chemin le plus rapide consiste à dire la réponse à voix haute à quelque chose qui peut réellement réagir.

FAQ

Q : Que signifie == en C, et en quoi est-ce différent de = ?

`==` est l’opérateur d’égalité — il vérifie si deux valeurs sont égales et renvoie 1 (vrai) ou 0 (faux). `=` est l’opérateur d’affectation — il stocke une valeur dans une variable et s’évalue à cette valeur stockée. La différence critique est que `=` modifie l’état du programme tandis que `==` se contente de l’inspecter. Écrire `=` dans une condition `if` est une syntaxe C valide et sera compilé, ce qui explique précisément pourquoi les intervieweurs testent cette distinction.

Q : Pourquoi une comparaison en C renvoie-t-elle 1 ou 0 au lieu de true ou false ?

Le système de types de C ne dispose pas d’un type booléen natif en C89. Les opérateurs relationnels et d’égalité sont définis par la norme du langage pour renvoyer des valeurs `int` : 1 pour une condition vraie, 0 pour une fausse. C99 a ajouté `_Bool` et l’en-tête `<stdbool.h>` avec les macros `true` et `false`, mais ces macros se développent respectivement en 1 et 0. Dans un contexte conditionnel, tout entier non nul est traité comme vrai.

Q : Quand dois-je utiliser ==, !=, <, >, <= ou >= dans les `if` et les boucles ?

Utilisez `==` lorsque vous avez besoin d’une égalité exacte, `!=` lorsque vous devez détecter une différence, et `<`, `>`, `<=`, `>=` lorsque vous devez établir un ordre ou un intervalle. Dans les boucles, le motif le plus courant est `<` pour une itération basée sur un index (`i < n`) et `!=` pour une itération basée sur un sentinelle. Le choix doit correspondre à la question sémantique que vous posez réellement — pas seulement à celle qui fonctionne pour vos cas de test.

Q : Pourquoi comparer des nombres à virgule flottante avec == peut-il être risqué ?

Les nombres à virgule flottante sont stockés en binaire avec une précision finie, et la plupart des fractions décimales ne peuvent pas être représentées exactement. Les calculs sur les flottants accumulent des erreurs d’arrondi, donc deux valeurs mathématiquement égales diffèrent souvent d’une très petite quantité dans leur forme binaire. L’alternative sûre est une comparaison avec tolérance : vérifiez si la différence absolue entre les deux valeurs est inférieure à un epsilon acceptable, en utilisant typiquement `fabsf` ou `fabs` depuis `<math.h>`.

Q : Comment comparer correctement des chaînes en C si == ne fonctionne pas ?

Utilisez `strcmp` depuis `<string.h>`. Elle compare le contenu des caractères de deux chaînes et renvoie 0 si elles sont égales, une valeur négative si la première est lexicographiquement inférieure, et une valeur positive si elle est supérieure. La raison pour laquelle `==` échoue est que les variables de chaîne en C sont des pointeurs — `==` compare des adresses mémoire, pas le contenu textuel. Deux chaînes ayant le même texte mais stockées à des emplacements mémoire différents ne seront pas égales avec `==`.

Q : Quelles sont les erreurs d’entretien les plus courantes liées à l’égalité en C ?

Les sept les plus testées : utiliser `=` au lieu de `==` dans une condition, ne pas savoir que les résultats de comparaison valent 1 ou 0, mal utiliser l’un des six opérateurs de comparaison dans une boucle, compter sur la priorité des opérateurs au lieu d’utiliser des parenthèses lorsqu’on mélange `=` et `==`, utiliser `==` pour comparer des chaînes au lieu de `strcmp`, utiliser `==` pour comparer des pointeurs alors que l’objectif était de comparer les valeurs, et utiliser `==` pour comparer des flottants au lieu d’un test de tolérance. Chacune paraît simple isolément et devient un vrai bug sous pression.

Q : En quoi la comparaison de pointeurs diffère-t-elle de la comparaison de valeurs en C ?

`p1 == p2` vérifie si deux pointeurs contiennent la même adresse mémoire — s’ils pointent vers le même objet. `p1 == p2` déréférence d’abord les deux pointeurs puis compare les valeurs stockées à ces adresses. Ce sont deux questions complètement différentes. Les intervieweurs testent cela parce que les candidats disent souvent « je vérifie s’ils sont égaux » sans préciser en quel sens, ce qui montre qu’ils n’ont pas encore bien séparé l’identité d’adresse de l’égalité de valeur dans leur modèle mental.

Conclusion

Les sept pièges de ce guide ne sont pas des cas limites obscurs. Ce sont précisément les endroits où la conception de C s’écarte de ce que l’intuition d’un débutant prédirait — et les intervieweurs le savent, car ils ont vu des candidats trébucher sur les mêmes erreurs à répétition. Mémoriser les symboles n’est pas l’objectif. L’objectif est d’être capable d’expliquer à voix haute pourquoi `==` échoue sur les chaînes, pourquoi les flottants ont besoin d’un test de tolérance, et pourquoi un avertissement du compilateur sur une affectation dans une condition n’est pas une suggestion.

Le moyen le plus rapide d’arrêter de paraître hésitant sur ces questions est de vous entraîner à formuler les réponses, pas seulement à les relire. Choisissez n’importe quels trois pièges parmi les sept, fermez l’article et expliquez chacun d’eux au mur. Si vous bloquez sur l’explication, vous avez trouvé exactement ce qui reste à travailler — avant que l’intervieweur ne le trouve en premier.