Je cherche un moyen de connaitre la position d'une occurence dans une chaine
J'ai essayé :
temp = strstr(bufferspace, "truc");
taille = temp-bufferspace;
Ne fonctionne pas car temp peut prendre la valeur NULL et donc le
compilateur refuse.
Etant dans l'espace noyau, je n'ai accès qu'a des fonctions sortant un
pointeur, et non la position.
| > Au contraire, j'ai affirmé qu'il était superflu de s'imposer | > l'ajout de lignes de code du genre: | > | > #ifdef __cplusplus | > #error Please use a C-compiler | > #endif | > | > Car la personne qui a recommandé leur usage semble encore vivre | > à l'époque du K&R C, et confondre l'ISO C avec du C++ ... | | Et moi, je dis que tu racontes n'importe quoi.
Vraiment? Dans ce cas, je t'invite à m'indiquer le passage d'un standard ANSI C (version de ton choix) qui définit que les types char et unsigned char sont équivalents. La version du standard C99 que j'ai sous la main indique le contraire (Par 6.5.6/3 et 6.2.5).
Je n'ai pas dit qu'ils étaient équivallent ni compatibles, mais
- il s'agit d'une différence de pointeurs et non pas des types de base. - de ce que j'en ai lu, la norme n'impose pas de diagnostic bloquant si les types pointés sont différents. - Visiblement, en C++ le diagnostic bloquant est requis, d'où mon insistance à ne pas confondre les deux langages et à s'assurer que le compilateur invoqué est le bon. Ce qui est permis avec l'un peut être interdit avec l'autre. - A ma connaissance (j'attend les contre-manips) l'erreur indiquée ne se produit que sur une version récente de gcc. De plus, elle ne semble pas concerner un problème de types incompatibles, mais plutôt une erreur de production de code (peut être consécutive à cette différence de type).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', "Ivan Vecerina" <ivec@myrealbox.com> wrote:
| > Au contraire, j'ai affirmé qu'il était superflu de s'imposer
| > l'ajout de lignes de code du genre:
| >
| > #ifdef __cplusplus
| > #error Please use a C-compiler
| > #endif
| >
| > Car la personne qui a recommandé leur usage semble encore vivre
| > à l'époque du K&R C, et confondre l'ISO C avec du C++ ...
|
| Et moi, je dis que tu racontes n'importe quoi.
Vraiment?
Dans ce cas, je t'invite à m'indiquer le passage d'un standard
ANSI C (version de ton choix) qui définit que les types char
et unsigned char sont équivalents. La version du standard C99
que j'ai sous la main indique le contraire (Par 6.5.6/3 et 6.2.5).
Je n'ai pas dit qu'ils étaient équivallent ni compatibles, mais
- il s'agit d'une différence de pointeurs et non pas des types de base.
- de ce que j'en ai lu, la norme n'impose pas de diagnostic bloquant si les
types pointés sont différents.
- Visiblement, en C++ le diagnostic bloquant est requis, d'où mon insistance
à ne pas confondre les deux langages et à s'assurer que le compilateur
invoqué est le bon. Ce qui est permis avec l'un peut être interdit avec
l'autre.
- A ma connaissance (j'attend les contre-manips) l'erreur indiquée ne se
produit que sur une version récente de gcc. De plus, elle ne semble pas
concerner un problème de types incompatibles, mais plutôt une erreur de
production de code (peut être consécutive à cette différence de type).
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
| > Au contraire, j'ai affirmé qu'il était superflu de s'imposer | > l'ajout de lignes de code du genre: | > | > #ifdef __cplusplus | > #error Please use a C-compiler | > #endif | > | > Car la personne qui a recommandé leur usage semble encore vivre | > à l'époque du K&R C, et confondre l'ISO C avec du C++ ... | | Et moi, je dis que tu racontes n'importe quoi.
Vraiment? Dans ce cas, je t'invite à m'indiquer le passage d'un standard ANSI C (version de ton choix) qui définit que les types char et unsigned char sont équivalents. La version du standard C99 que j'ai sous la main indique le contraire (Par 6.5.6/3 et 6.2.5).
Je n'ai pas dit qu'ils étaient équivallent ni compatibles, mais
- il s'agit d'une différence de pointeurs et non pas des types de base. - de ce que j'en ai lu, la norme n'impose pas de diagnostic bloquant si les types pointés sont différents. - Visiblement, en C++ le diagnostic bloquant est requis, d'où mon insistance à ne pas confondre les deux langages et à s'assurer que le compilateur invoqué est le bon. Ce qui est permis avec l'un peut être interdit avec l'autre. - A ma connaissance (j'attend les contre-manips) l'erreur indiquée ne se produit que sur une version récente de gcc. De plus, elle ne semble pas concerner un problème de types incompatibles, mais plutôt une erreur de production de code (peut être consécutive à cette différence de type).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Gabriel Dos Reis
Emmanuel Delahaye writes:
| In 'fr.comp.lang.c', Francois Cartegnie wrote: | | >> est-tu sûr que tu utilises un compilateur C et non C++? | >> | >> Mets ça dans ton code (n'importe où) | >> | >> #ifdef __cplusplus | >> #error Please use a C-compiler | >> #endif | >> | > | > GCC 3.2... | | gcc n'est pas un compilateur 'simple'. Il est capable d'appeler g++ si | l'extension est .C ou .cpp.
Cela est sans importance dans ce cas précis : soustraire un 'char*' d'un 'unsignec char*' n'est simplement pas valide.
-- Gaby
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
| In 'fr.comp.lang.c', Francois Cartegnie <NOSPAM@TAMAMAN.OWC> wrote:
|
| >> est-tu sûr que tu utilises un compilateur C et non C++?
| >>
| >> Mets ça dans ton code (n'importe où)
| >>
| >> #ifdef __cplusplus
| >> #error Please use a C-compiler
| >> #endif
| >>
| >
| > GCC 3.2...
|
| gcc n'est pas un compilateur 'simple'. Il est capable d'appeler g++ si
| l'extension est .C ou .cpp.
Cela est sans importance dans ce cas précis : soustraire un 'char*'
d'un 'unsignec char*' n'est simplement pas valide.
| In 'fr.comp.lang.c', Francois Cartegnie wrote: | | >> est-tu sûr que tu utilises un compilateur C et non C++? | >> | >> Mets ça dans ton code (n'importe où) | >> | >> #ifdef __cplusplus | >> #error Please use a C-compiler | >> #endif | >> | > | > GCC 3.2... | | gcc n'est pas un compilateur 'simple'. Il est capable d'appeler g++ si | l'extension est .C ou .cpp.
Cela est sans importance dans ce cas précis : soustraire un 'char*' d'un 'unsignec char*' n'est simplement pas valide.
-- Gaby
Gabriel Dos Reis
Emmanuel Delahaye writes:
| > Pour les compilateurs egalement, la synergie entre certains languages | > est evidente. Surtout entre le C et le C++. | | Il n'y a aucune synergie entre ces langages.
Tu fais cette affirmation en tant que ?
-- Gaby
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
| > Pour les compilateurs egalement, la synergie entre certains languages
| > est evidente. Surtout entre le C et le C++.
|
| Il n'y a aucune synergie entre ces langages.
| > Pour les compilateurs egalement, la synergie entre certains languages | > est evidente. Surtout entre le C et le C++. | | Il n'y a aucune synergie entre ces langages.
Tu fais cette affirmation en tant que ?
-- Gaby
Gabriel Dos Reis
Emmanuel Delahaye writes:
| In 'fr.comp.lang.c', "Ivan Vecerina" wrote: | | > Au contraire, j'ai affirmé qu'il était superflu de s'imposer | > l'ajout de lignes de code du genre: | > | > #ifdef __cplusplus | > #error Please use a C-compiler | > #endif | > | > Car la personne qui a recommandé leur usage semble encore vivre | > à l'époque du K&R C, et confondre l'ISO C avec du C++ ... | | Et moi, je dis que tu racontes n'importe quoi.
En l'occurence la personne dont la cervelle a totalement fondu est toi. La construction présentée est invalide, c'est comme ça.
-- Gaby
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
| In 'fr.comp.lang.c', "Ivan Vecerina" <ivec@myrealbox.com> wrote:
|
| > Au contraire, j'ai affirmé qu'il était superflu de s'imposer
| > l'ajout de lignes de code du genre:
| >
| > #ifdef __cplusplus
| > #error Please use a C-compiler
| > #endif
| >
| > Car la personne qui a recommandé leur usage semble encore vivre
| > à l'époque du K&R C, et confondre l'ISO C avec du C++ ...
|
| Et moi, je dis que tu racontes n'importe quoi.
En l'occurence la personne dont la cervelle a totalement fondu est toi.
La construction présentée est invalide, c'est comme ça.
| In 'fr.comp.lang.c', "Ivan Vecerina" wrote: | | > Au contraire, j'ai affirmé qu'il était superflu de s'imposer | > l'ajout de lignes de code du genre: | > | > #ifdef __cplusplus | > #error Please use a C-compiler | > #endif | > | > Car la personne qui a recommandé leur usage semble encore vivre | > à l'époque du K&R C, et confondre l'ISO C avec du C++ ... | | Et moi, je dis que tu racontes n'importe quoi.
En l'occurence la personne dont la cervelle a totalement fondu est toi. La construction présentée est invalide, c'est comme ça.
-- Gaby
Gabriel Dos Reis
"Ivan Vecerina" writes:
| Je rentre emmener mes gamins a la piscine, assez perdu de temps.
Tu ne veux pas emmener Emmanuel aussi, s'itl te plaît ?
-- Gaby
"Ivan Vecerina" <ivec@myrealbox.com> writes:
| Je rentre emmener mes gamins a la piscine, assez perdu de temps.
Tu ne veux pas emmener Emmanuel aussi, s'itl te plaît ?
| Je rentre emmener mes gamins a la piscine, assez perdu de temps.
Tu ne veux pas emmener Emmanuel aussi, s'itl te plaît ?
-- Gaby
Serge Paccalin
Le mardi 5 août 2003 à 18:05, Gabriel Dos Reis a écrit dans fr.comp.lang.c :
Serge Paccalin writes:
| Le mardi 5 août 2003 à 15:31, Gabriel Dos Reis a écrit dans | fr.comp.lang.c : | |>| est-tu sûr que tu utilises un compilateur C et non C++? | |> qu'est-ce que ça change en ce qui concerne unsigned char* et char* ? | | Avec Visual Studio 6.0, ça change ça :
Je ne sais pas si tu as bien suivi la disussion mais il s'agissait de savoir si p - q est bien formé sachant que p est de type 'unsigned char*' et q de type 'char*'.
J'ai suivi.
Le fait que ton compilo l'accepte ou le rejete suivant le flag que tu mets n'est pas une preuve que c'est bien formé.
Tout à fait d'accord. Dois-je en déduire que le compilateur est buggé sur ce point ?
Dans la norme du C, on a : 6.5.6 3 For subtraction, one of the following shall hold: -- both operands are pointers to qualified or unqualified versions of **compatible** object types;
Dans la norme du C++ : 5.7
2 For subtraction, one of the following shall hold: -- both operands are pointers to cv-qualified or cv-unqualified versions of **the same completely defined** object type;
-- ___________ 2003-08-05 18:10:39 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Le mardi 5 août 2003 à 18:05, Gabriel Dos Reis a écrit dans
fr.comp.lang.c :
| Le mardi 5 août 2003 à 15:31, Gabriel Dos Reis a écrit dans
| fr.comp.lang.c :
|
|>| est-tu sûr que tu utilises un compilateur C et non C++?
|
|> qu'est-ce que ça change en ce qui concerne unsigned char* et char* ?
|
| Avec Visual Studio 6.0, ça change ça :
Je ne sais pas si tu as bien suivi la disussion mais il s'agissait de
savoir si p - q est bien formé sachant que p est de type 'unsigned
char*' et q de type 'char*'.
J'ai suivi.
Le fait que ton compilo l'accepte ou le rejete suivant le flag que tu
mets n'est pas une preuve que c'est bien formé.
Tout à fait d'accord. Dois-je en déduire que le compilateur est buggé
sur ce point ?
Dans la norme du C, on a :
6.5.6
3 For subtraction, one of the following shall hold:
-- both operands are pointers to qualified or unqualified versions of
**compatible** object types;
Dans la norme du C++ :
5.7
2 For subtraction, one of the following shall hold:
-- both operands are pointers to cv-qualified or cv-unqualified versions
of **the same completely defined** object type;
--
___________ 2003-08-05 18:10:39
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Le mardi 5 août 2003 à 18:05, Gabriel Dos Reis a écrit dans fr.comp.lang.c :
Serge Paccalin writes:
| Le mardi 5 août 2003 à 15:31, Gabriel Dos Reis a écrit dans | fr.comp.lang.c : | |>| est-tu sûr que tu utilises un compilateur C et non C++? | |> qu'est-ce que ça change en ce qui concerne unsigned char* et char* ? | | Avec Visual Studio 6.0, ça change ça :
Je ne sais pas si tu as bien suivi la disussion mais il s'agissait de savoir si p - q est bien formé sachant que p est de type 'unsigned char*' et q de type 'char*'.
J'ai suivi.
Le fait que ton compilo l'accepte ou le rejete suivant le flag que tu mets n'est pas une preuve que c'est bien formé.
Tout à fait d'accord. Dois-je en déduire que le compilateur est buggé sur ce point ?
Dans la norme du C, on a : 6.5.6 3 For subtraction, one of the following shall hold: -- both operands are pointers to qualified or unqualified versions of **compatible** object types;
Dans la norme du C++ : 5.7
2 For subtraction, one of the following shall hold: -- both operands are pointers to cv-qualified or cv-unqualified versions of **the same completely defined** object type;
-- ___________ 2003-08-05 18:10:39 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
| "Ivan Vecerina" écrivait : | | > Aucune synergie ?? | > | > Pourrais-tu m'indiquer une seule implémentation de la librairie stand ard | > du C++ qui ne contienne pas également une implémentation de la libr airie | > standard C ? Qui ne réutilise pas celle-ci ? | | Je ne vois pas ce que ça a à voir avec l'exigence que les programmeurs | C se limitent à l'intersection de C et C++.
Emmanuel a fait l'assertion (fausse) qu'il n'existe aucune synergie entre les deux comités alors même qu'une simple visite sur le site du comité de son choix lui aurait permit de ne pas louper l'occasion de se taire.
| "Ivan Vecerina" <ivec@myrealbox.com> écrivait :
|
| > Aucune synergie ??
| >
| > Pourrais-tu m'indiquer une seule implémentation de la librairie stand ard
| > du C++ qui ne contienne pas également une implémentation de la libr airie
| > standard C ? Qui ne réutilise pas celle-ci ?
|
| Je ne vois pas ce que ça a à voir avec l'exigence que les programmeurs
| C se limitent à l'intersection de C et C++.
Emmanuel a fait l'assertion (fausse) qu'il n'existe aucune synergie
entre les deux comités alors même qu'une simple visite sur le site du
comité de son choix lui aurait permit de ne pas louper l'occasion de
se taire.
| "Ivan Vecerina" écrivait : | | > Aucune synergie ?? | > | > Pourrais-tu m'indiquer une seule implémentation de la librairie stand ard | > du C++ qui ne contienne pas également une implémentation de la libr airie | > standard C ? Qui ne réutilise pas celle-ci ? | | Je ne vois pas ce que ça a à voir avec l'exigence que les programmeurs | C se limitent à l'intersection de C et C++.
Emmanuel a fait l'assertion (fausse) qu'il n'existe aucune synergie entre les deux comités alors même qu'une simple visite sur le site du comité de son choix lui aurait permit de ne pas louper l'occasion de se taire.
-- Gaby
--=-=-=--
Laurent Deniau
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Gabriel Dos Reis wrote:
| > GCC 3.2... | > | | Pour exemple, ce code passe pas a la compilation et génère un | " invalid operands to binary - "
comme cela se doit.
Il se trouve juste qu'il y a sur ce groupe quelques herétiques qui utilisent des armes de distraction massive pour qu'on ne s'aperçoive pas qu'ils ne comprennent pas le C.
[#3] For subtraction, one of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or unqualified versions of compatible object types; or
-- the left operand is a pointer to an object type and the right operand has integer type.
(Decrementing is equivalent to subtracting 1.)
[...]
35)CHAR_MIN, defined in <limits.h>, will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the two options. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either.
Je ne vois pas écrit qu'il faille un diagnostic et arréter la compilation si un opérande est signé et l'autre non. Mais toi qui a une meilleure vue que moi, tu va me dire où c'est écrit.
parce qu'un char n'est ni signe ni non signe. la norme dit clairement (derniere ligne) que char est un cas a part. en particulier on a la garantie que sizeof(signed char) == sizeof(unsigned char) mais pas sizeof(char) == sizeof(signed char) d'ou le probleme dans la soustraction...
mettre un signed devant le premier char devrait resoudre le probleme.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne serait-ce pas un bug par hasard? Tout est possible...
non ce n'est pas un bug. le code est un UB.
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > GCC 3.2...
| >
|
| Pour exemple, ce code passe pas a la compilation et génère un
| " invalid operands to binary - "
comme cela se doit.
Il se trouve juste qu'il y a sur ce groupe quelques herétiques qui
utilisent des armes de distraction massive pour qu'on ne
s'aperçoive pas qu'ils ne comprennent pas le C.
[#3] For subtraction, one of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or unqualified
versions of compatible object types; or
-- the left operand is a pointer to an object type and the
right operand has integer type.
(Decrementing is equivalent to subtracting 1.)
[...]
35)CHAR_MIN, defined in <limits.h>, will have one of the
values 0 or SCHAR_MIN, and this can be used to
distinguish the two options. Irrespective of the choice
made, char is a separate type from the other two and is
not compatible with either.
Je ne vois pas écrit qu'il faille un diagnostic et arréter la compilation si
un opérande est signé et l'autre non. Mais toi qui a une meilleure vue que
moi, tu va me dire où c'est écrit.
parce qu'un char n'est ni signe ni non signe. la norme dit clairement (derniere
ligne) que char est un cas a part. en particulier on a la garantie que
sizeof(signed char) == sizeof(unsigned char) mais pas sizeof(char) ==
sizeof(signed char) d'ou le probleme dans la soustraction...
mettre un signed devant le premier char devrait resoudre le probleme.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne serait-ce
pas un bug par hasard? Tout est possible...
non ce n'est pas un bug. le code est un UB.
a+, ld.
--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]
| > GCC 3.2... | > | | Pour exemple, ce code passe pas a la compilation et génère un | " invalid operands to binary - "
comme cela se doit.
Il se trouve juste qu'il y a sur ce groupe quelques herétiques qui utilisent des armes de distraction massive pour qu'on ne s'aperçoive pas qu'ils ne comprennent pas le C.
[#3] For subtraction, one of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or unqualified versions of compatible object types; or
-- the left operand is a pointer to an object type and the right operand has integer type.
(Decrementing is equivalent to subtracting 1.)
[...]
35)CHAR_MIN, defined in <limits.h>, will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the two options. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either.
Je ne vois pas écrit qu'il faille un diagnostic et arréter la compilation si un opérande est signé et l'autre non. Mais toi qui a une meilleure vue que moi, tu va me dire où c'est écrit.
parce qu'un char n'est ni signe ni non signe. la norme dit clairement (derniere ligne) que char est un cas a part. en particulier on a la garantie que sizeof(signed char) == sizeof(unsigned char) mais pas sizeof(char) == sizeof(signed char) d'ou le probleme dans la soustraction...
mettre un signed devant le premier char devrait resoudre le probleme.
Par contre, as-tu bien compris le sens du message émis par gcc? Ne serait-ce pas un bug par hasard? Tout est possible...
non ce n'est pas un bug. le code est un UB.
a+, ld.
-- [ Laurent Deniau -- Scientific Computing & Data Analysis ] [ CERN -- European Center for Nuclear Research ] [ - http://cern.ch/Laurent.Deniau ] [ -- One becomes old when dreams become regrets -- ]
Emmanuel Delahaye
In 'fr.comp.lang.c', Gabriel Dos Reis wrote:
Inutile. Ton incompétance est aveuglante. Fais moi plaisir, relis:
[#3] For subtraction, one of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or unqualified versions of compatible object types; or
-- the left operand is a pointer to an object type and the right operand has integer type.
(Decrementing is equivalent to subtracting 1.)
Je comprends que pour la soustraction, une de ces trois conditions est requise:
-- Les deux opérandes ont un type arithmetique.
pas de chance ce sont deux pointeurs, condition suivante:
-- Les deux opérandes sont être de type pointeurs vers des objets compatibles, qualifiés ou non.
C'est le cas de l'OP.
Question, 'char *' est il compatible avec 'unsigned char *'? Pour moi, oui, mais je veux bien qu'on me démontre le contraire.
-- L'opérande de gauche est de type pointeur vers un objet et celui de droite est un entier.
Ce n'est pas le cas demandé.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Gabriel Dos Reis <gdr@integrable-solutions.net>
wrote:
Inutile. Ton incompétance est aveuglante. Fais moi plaisir, relis:
[#3] For subtraction, one of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or unqualified
versions of compatible object types; or
-- the left operand is a pointer to an object type and the
right operand has integer type.
(Decrementing is equivalent to subtracting 1.)
Je comprends que pour la soustraction, une de ces trois conditions est
requise:
-- Les deux opérandes ont un type arithmetique.
pas de chance ce sont deux pointeurs, condition suivante:
-- Les deux opérandes sont être de type pointeurs vers des objets
compatibles, qualifiés ou non.
C'est le cas de l'OP.
Question, 'char *' est il compatible avec 'unsigned char *'? Pour moi, oui,
mais je veux bien qu'on me démontre le contraire.
-- L'opérande de gauche est de type pointeur vers un objet et celui de droite
est un entier.
Ce n'est pas le cas demandé.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
