Comportement de strcmp

Version imprimable

09/12/2010, 00h57
vincent-v

Comportement de strcmp
Bonjour à tous,

Je n'arrive pas à comprendre pourquoi ce test est toujours faux... la fonction strcmp n'est elle pas sensé comparer seulement les n (4 dans mon exemple) premiers caractères ?
Code:

1 2 3 4 5 if(strcmp("help", "help0", 4) == 0) { printHelp(); return; }
Je suis sous Ubuntu et j'utilise gcc 4.4.3

Merci d'avance pour vos réponses ;)
09/12/2010, 01h07
jeroman

Salut

Il faut utiliser strncmp et non strcmp. Le compilateur génère des warning s'il est bien réglé. ;)
09/12/2010, 11h40
ram-0000

Code:

if(strcmp("help", "help0", 4) == 0)

Cela n'aurait jamais du passer avec un compilateur bien réglé.

La page man de strcmp indique clairement que strcmp attend 2 paramètres et pas 3 comme tu l'as fait.
09/12/2010, 15h21
6-MarViN

Ton compilateur ne t'a pas craché tout son venin à la figure? Impressionnant! Sinon la fonction que tu recherche est strncmp().
11/12/2010, 11h45
uknow

Citation:

Envoyé par ram-0000

Code:

if(strcmp("help", "help0", 4) == 0)

Cela n'aurait jamais du passer avec un compilateur bien réglé.

Si le compilateur fait une déclaration implicite parce qu'on a oublié d'inclure string.h, alors l'erreur peut être masquée (c'est indépendant des réglages du compilateur me semble-t-il).
11/12/2010, 13h31
ram-0000

Citation:

Envoyé par uknow

Si le compilateur fait une déclaration implicite parce qu'on a oublié d'inclure string.h, alors l'erreur peut être masquée (c'est indépendant des réglages du compilateur me semble-t-il).

Avec les bons réglages, le compilateur émet au moins un warning "unknown function strcmp()"
11/12/2010, 13h50
uknow

Citation:

Envoyé par ram-0000

Avec les bons réglages, le compilateur émet au moins un warning "unknown function strcmp()"

Oui, mais on n'obtient ce type d'erreur que si on "inhibe" les déclarations implicites (chose qui ne me semble pas être faisable par utilisation des options de compilation, je me trompe ?!), ou si le compilateur est assez intelligent pour savoir qu'il s'agit de la fonction dont la déclaration est dans string.h que nous n'avons pas inclus.

GCC retourne un message d'erreur "en bonus" sur une mauvaise utilisation des fonctions standards même sans qu'on ait inclut les "headers" associés, donc le problème est réglé. Mais je suppose que tous les compilateurs ne sont pas pareils à ce niveau.
11/12/2010, 14h21
gl

Citation:

Envoyé par uknow

Oui, mais on n'obtient ce type d'erreur que si on "inhibe" les déclarations implicites (chose qui ne me semble pas être faisable par utilisation des options de compilation, je me trompe ?!), ou si le compilateur est assez intelligent pour savoir qu'il s'agit de la fonction dont la déclaration est dans string.h que nous n'avons pas inclus.

Non.

Par exemple, gcc (mais cela est vrai pour d'autre compilateurs) correctement réglé remonte bien un warning du type de celui indiqué par ram-000 sans pour autant inhiber la déclaration implicite (le code compile) même sur des fonctions personnelles :

Citation:

C:\data\Workspace\C\DVP\main.c|6|warning: implicit declaration of function 'test'|
11/12/2010, 16h25
uknow

Citation:

Envoyé par gl

Par exemple, gcc (mais cela est vrai pour d'autre compilateurs) correctement réglé remonte bien un warning du type de celui indiqué par ram-000 sans pour autant inhiber la déclaration implicite (le code compile) même sur des fonctions personnelles :

Oui on est d'accord, mais il s'agit d'un warning sur une déclaration implicite, et pas sur une mauvaise utilisation d'une fonction, telle que le post suivant laisserait entendre :

Citation:

Cela n'aurait jamais du passer avec un compilateur bien réglé.

(J'interprète mal peut être ?!).

Ce que je veux souligner est que le seul moyen de remonter une erreur de compilation proprement dite est d'inclure string.h. Chose qui permettrait au compilateur de vérifier la validité des arguments et de retourner une erreur du type : "Too many arguments to function strcmp." ce qui n'a rien à voir avec sa configuration. D'autre part on ne peut pas lui en vouloir s'il ne l'indique pas alors qu'on a oublié de déclarer cette fonction.
11/12/2010, 17h04
ram-0000

Citation:

Envoyé par uknow

Oui on est d'accord, mais il s'agit d'un warning sur une déclaration implicite, et pas sur une mauvaise utilisation d'une fonction, telle que le post suivant laisserait entendre :

Tout à fait d'accord.

Citation:

Envoyé par uknow

Ce que je veux souligner est que le seul moyen de remonter une erreur de compilation proprement dite est d'inclure string.h. Chose qui permettrait au compilateur de vérifier la validité des arguments et de retourner une erreur du type : "Too many arguments to function strcmp."

Tout à fait d'accord encore

Ceci dit, derrière chaque warning du compilateur se cache une erreur potentielle et la prudence et l'expérience m'ont appris à ne pas ignorer ces warning et à les traiter comme des erreurts (même si le compilateur a généré un binaire exécutable).

Et d'ailleurs, dans Visual Studio, il y a une option du compilateur (l'option /WX) qui dit "traiter les warning comme des erreurs'.
11/12/2010, 17h14
uknow

Citation:

Envoyé par ram-0000

Et d'ailleurs, dans Visual Studio, il y a une option du compilateur (l'option /WX) qui dit "traiter les warning comme des erreurs'.

Je suis du même avis concernant les "warnings" je les associe même à des bogues potentiels. L'option pour GCC est -werror.
11/12/2010, 18h41
gl

Citation:

Envoyé par uknow

Ce que je veux souligner est que le seul moyen de remonter une erreur de compilation proprement dite est d'inclure string.h. Chose qui permettrait au compilateur de vérifier la validité des arguments et de retourner une erreur du type : "Too many arguments to function strcmp." ce qui n'a rien à voir avec sa configuration. D'autre part on ne peut pas lui en vouloir s'il ne l'indique pas alors qu'on a oublié de déclarer cette fonction.

Par le warning, le compilateur signale bien le problème (utilisation d'une fonction inconnue, donc pas de vérification de cohérence entre le prototype et l'appel).

Je comprends ton raisonnement dans le sens où il ne pointe pas explicitement le problème du nombre de paramètres. Toutefois il signale bien qu'il y a un problème.