Discussion :

[vincent-v]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[jeroman]

Salut

Il faut utiliser strncmp et non strcmp. Le compilateur génère des warning s'il est bien réglé.

[ram-0000]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[6-MarViN]

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

[uknow]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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).

[ram-0000]

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()"

[uknow]

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.

[gl]

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 :

C:\data\Workspace\C\DVP\main.c|6|warning: implicit declaration of function 'test'|

[uknow]

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 :

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.

[ram-0000]

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.

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'.

[uknow]

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.

[gl]

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.