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.
Serge Paccalin writes: | Je reformule : | | - Considères-tu que « char » et « unsigned char » sont des types | d'objets compatibles (au sens où la norme C comprend ce terme) ?
La norme C dit que ce ne sont pas deux types comptibles. La question est donc réglée de ce côté là.
| - Considères-tu que « char » et « unsigned char » sont le même type | d'objet complètement défini (au sens où la norme C++ comprend ces | termes) ?
La norme C++ (tout comme la norme C) dit que ce sont deux types différents. La question est aussi reglée de ce côté là.
En conclusion, les deux normes sont d'accord pour rejeter le programme -- chacune avec sa formulation.
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas. Ce n'est pas ce que j'appelle « oui » et « non ».
| n'ai pas d'avis tranché sur ces questions, je tiens juste compte des | choix d'implantation faits dans l'outil que j'utilise tous les jours.
Je comprends.
-- Gaby
Serge Paccalin <sp@mailclub.no.spam.net.invalid> writes:
| Je reformule :
|
| - Considères-tu que « char » et « unsigned char » sont des types
| d'objets compatibles (au sens où la norme C comprend ce terme) ?
La norme C dit que ce ne sont pas deux types comptibles. La question
est donc réglée de ce côté là.
| - Considères-tu que « char » et « unsigned char » sont le même type
| d'objet complètement défini (au sens où la norme C++ comprend ces
| termes) ?
La norme C++ (tout comme la norme C) dit que ce sont deux types
différents. La question est aussi reglée de ce côté là.
En conclusion, les deux normes sont d'accord pour rejeter le programme
-- chacune avec sa formulation.
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas.
Ce n'est pas ce que j'appelle « oui » et « non ».
| n'ai pas d'avis tranché sur ces questions, je tiens juste compte des
| choix d'implantation faits dans l'outil que j'utilise tous les jours.
Serge Paccalin writes: | Je reformule : | | - Considères-tu que « char » et « unsigned char » sont des types | d'objets compatibles (au sens où la norme C comprend ce terme) ?
La norme C dit que ce ne sont pas deux types comptibles. La question est donc réglée de ce côté là.
| - Considères-tu que « char » et « unsigned char » sont le même type | d'objet complètement défini (au sens où la norme C++ comprend ces | termes) ?
La norme C++ (tout comme la norme C) dit que ce sont deux types différents. La question est aussi reglée de ce côté là.
En conclusion, les deux normes sont d'accord pour rejeter le programme -- chacune avec sa formulation.
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas. Ce n'est pas ce que j'appelle « oui » et « non ».
| n'ai pas d'avis tranché sur ces questions, je tiens juste compte des | choix d'implantation faits dans l'outil que j'utilise tous les jours.
Je comprends.
-- Gaby
Laurent Deniau
Gabriel Dos Reis wrote:
Laurent Deniau writes:
| Richard Delorme wrote: | > | >>Richard Delorme écrivait : | >> | >> | >>>D'après la norme signed char et unsigned char ne sont pas des types | >>>compatibles. Or la norme n'autorise la soustraction que de pointeur vers | >>>des types compatibles. Ton compilateur a donc raison si char est signé. | >> | >>Et mêm si char est non signé d'ailleurs. | >> | > En effet, char, signed char et unsigned char sont trois types | > différents. | | oui mais signed char et unsigned char sont compatibles. | char est a part. sizeof(char) == 1 tandis que sizeof(signed char) = > | sizeof(unsigned char) >= 1
Je suis très curieux de savoir d'où tu tires ces conclusions.
Au vu de la norme je suis d'accord (cf post de richard), il y a egalite a l'unite pour les trois types. Mais j'ai rencontre une plateforme risc (il y a qq annees, RS6000, MIPS ou Alpha, je ne sais plus) ou sizeof(char) == 1 et sizeof(signed char) == sizeof(unsigned char) == 4. Certe ce n'est pas la norme et ca ne fait pas office de reference (bug du compilo?) mais depuis je me mefie...
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 -- ]
Gabriel Dos Reis wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| Richard Delorme wrote:
| >
| >>Richard Delorme <abulmo@nospam.fr> écrivait :
| >>
| >>
| >>>D'après la norme signed char et unsigned char ne sont pas des types
| >>>compatibles. Or la norme n'autorise la soustraction que de pointeur vers
| >>>des types compatibles. Ton compilateur a donc raison si char est signé.
| >>
| >>Et mêm si char est non signé d'ailleurs.
| >>
| > En effet, char, signed char et unsigned char sont trois types
| > différents.
|
| oui mais signed char et unsigned char sont compatibles.
| char est a part. sizeof(char) == 1 tandis que sizeof(signed char) = > | sizeof(unsigned char) >= 1
Je suis très curieux de savoir d'où tu tires ces conclusions.
Au vu de la norme je suis d'accord (cf post de richard), il y a egalite a
l'unite pour les trois types. Mais j'ai rencontre une plateforme risc (il y a qq
annees, RS6000, MIPS ou Alpha, je ne sais plus) ou sizeof(char) == 1 et
sizeof(signed char) == sizeof(unsigned char) == 4. Certe ce n'est pas la norme
et ca ne fait pas office de reference (bug du compilo?) mais depuis je me mefie...
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 -- ]
| Richard Delorme wrote: | > | >>Richard Delorme écrivait : | >> | >> | >>>D'après la norme signed char et unsigned char ne sont pas des types | >>>compatibles. Or la norme n'autorise la soustraction que de pointeur vers | >>>des types compatibles. Ton compilateur a donc raison si char est signé. | >> | >>Et mêm si char est non signé d'ailleurs. | >> | > En effet, char, signed char et unsigned char sont trois types | > différents. | | oui mais signed char et unsigned char sont compatibles. | char est a part. sizeof(char) == 1 tandis que sizeof(signed char) = > | sizeof(unsigned char) >= 1
Je suis très curieux de savoir d'où tu tires ces conclusions.
Au vu de la norme je suis d'accord (cf post de richard), il y a egalite a l'unite pour les trois types. Mais j'ai rencontre une plateforme risc (il y a qq annees, RS6000, MIPS ou Alpha, je ne sais plus) ou sizeof(char) == 1 et sizeof(signed char) == sizeof(unsigned char) == 4. Certe ce n'est pas la norme et ca ne fait pas office de reference (bug du compilo?) mais depuis je me mefie...
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 -- ]
Serge Paccalin
Le mercredi 6 août 2003 à 09:45, Gabriel Dos Reis a écrit dans fr.comp.lang.c :
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas.
Mais il acceptait de générer du code. C'est un critère comme un autre.
Ce n'est pas ce que j'appelle « oui » et « non ».
Disons « oui mais » et « non ».
-- ___________ 2003-08-06 12:45:09 _/ _ _`_`_`_) 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 mercredi 6 août 2003 à 09:45, Gabriel Dos Reis a écrit dans
fr.comp.lang.c :
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas.
Mais il acceptait de générer du code. C'est un critère comme un autre.
Ce n'est pas ce que j'appelle « oui » et « non ».
Disons « oui mais » et « non ».
--
___________ 2003-08-06 12:45:09
_/ _ _`_`_`_) 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 mercredi 6 août 2003 à 09:45, Gabriel Dos Reis a écrit dans fr.comp.lang.c :
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas.
Mais il acceptait de générer du code. C'est un critère comme un autre.
Ce n'est pas ce que j'appelle « oui » et « non ».
Disons « oui mais » et « non ».
-- ___________ 2003-08-06 12:45:09 _/ _ _`_`_`_) 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
Gabriel Dos Reis
Serge Paccalin writes:
| Le mercredi 6 août 2003 à 09:45, Gabriel Dos Reis a écrit dans | fr.comp.lang.c : | | >| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je | | > De ce que tu m'as montré, il emettait un diagnostic dans les deux cas. | | Mais il acceptait de générer du code.
Accepter de générer du code ne veut pas dire « oui ». D'autant que le diagnostic ne prêtait pas à confusion.
| C'est un critère comme un autre. | | > Ce n'est pas ce que j'appelle « oui » et « non ». | | Disons « oui mais » et « non ».
C'est « je vous avertis que ce n'est pas valable » et « non ».
| Le mercredi 6 août 2003 à 09:45, Gabriel Dos Reis a écrit dans
| fr.comp.lang.c :
|
| >| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
|
| > De ce que tu m'as montré, il emettait un diagnostic dans les deux cas.
|
| Mais il acceptait de générer du code.
Accepter de générer du code ne veut pas dire « oui ». D'autant que le
diagnostic ne prêtait pas à confusion.
| C'est un critère comme un autre.
|
| > Ce n'est pas ce que j'appelle « oui » et « non ».
|
| Disons « oui mais » et « non ».
C'est « je vous avertis que ce n'est pas valable » et « non ».
| Le mercredi 6 août 2003 à 09:45, Gabriel Dos Reis a écrit dans | fr.comp.lang.c : | | >| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je | | > De ce que tu m'as montré, il emettait un diagnostic dans les deux cas. | | Mais il acceptait de générer du code.
Accepter de générer du code ne veut pas dire « oui ». D'autant que le diagnostic ne prêtait pas à confusion.
| C'est un critère comme un autre. | | > Ce n'est pas ce que j'appelle « oui » et « non ». | | Disons « oui mais » et « non ».
C'est « je vous avertis que ce n'est pas valable » et « non ».
-- Gaby
Gabriel Dos Reis
Laurent Deniau writes:
| Au vu de la norme je suis d'accord (cf post de richard), il y a | egalite a l'unite pour les trois types. Mais j'ai rencontre une | plateforme risc (il y a qq annees, RS6000, MIPS ou Alpha, je ne sais | plus) ou sizeof(char) == 1 et sizeof(signed char) == sizeof(unsigned | char) == 4. Certe ce n'est pas la norme et ca ne fait pas office de | reference (bug du compilo?) mais depuis je me mefie...
Il y a toujours des compilos buggués quelque part, c'est pour cela que nous sommes là :-)
-- gaby
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| Au vu de la norme je suis d'accord (cf post de richard), il y a
| egalite a l'unite pour les trois types. Mais j'ai rencontre une
| plateforme risc (il y a qq annees, RS6000, MIPS ou Alpha, je ne sais
| plus) ou sizeof(char) == 1 et sizeof(signed char) == sizeof(unsigned
| char) == 4. Certe ce n'est pas la norme et ca ne fait pas office de
| reference (bug du compilo?) mais depuis je me mefie...
Il y a toujours des compilos buggués quelque part, c'est pour cela que
nous sommes là :-)
| Au vu de la norme je suis d'accord (cf post de richard), il y a | egalite a l'unite pour les trois types. Mais j'ai rencontre une | plateforme risc (il y a qq annees, RS6000, MIPS ou Alpha, je ne sais | plus) ou sizeof(char) == 1 et sizeof(signed char) == sizeof(unsigned | char) == 4. Certe ce n'est pas la norme et ca ne fait pas office de | reference (bug du compilo?) mais depuis je me mefie...
Il y a toujours des compilos buggués quelque part, c'est pour cela que nous sommes là :-)
-- gaby
Gabriel Dos Reis
Laurent Deniau writes:
[...]
| > | - mais char a le meme comportement que soit signed char soit unsigned char | > Non. La norme ne dit pas ça. | | malheureusement si...
il n'y a pas de malheureusement; et j'ai mal lu ta phrase. Je l'ai comprise comme si elle voulait dire que char doit être pareil que soit 'signed char' ou 'unsigned char'.
| 6.2.5-15 | | The three types char, signed char, and unsigned char are collectively | called the character types. The implementation shall define char to | have the same range, representation, and behavior as either signed | char or unsigned char.32)
et en même temps, char doit être un type distinct.
Ce que la norme veut dire ici, c'est juste la formulation de ce qui se passe concretement sur une architrecture 32-bits ou int et long font 32 bits (disons un solaris-2.[567] sur un SPARC 32-bit par exemple).
Les deux types vont avoir alors les mêmes représentations, mais ils resteront néanmoins distincts et incompatibles. Ce n'est pas contradictoire. C'est simplement que la sémantique C (et C++ dans une certaine mesure) est orientée « token » et non « bits »
-- Gaby
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
[...]
| > | - mais char a le meme comportement que soit signed char soit unsigned char
| > Non. La norme ne dit pas ça.
|
| malheureusement si...
il n'y a pas de malheureusement; et j'ai mal lu ta phrase.
Je l'ai comprise comme si elle voulait dire que char doit être pareil
que soit 'signed char' ou 'unsigned char'.
| 6.2.5-15
|
| The three types char, signed char, and unsigned char are collectively
| called the character types. The implementation shall define char to
| have the same range, representation, and behavior as either signed
| char or unsigned char.32)
et en même temps, char doit être un type distinct.
Ce que la norme veut dire ici, c'est juste la formulation de ce qui se
passe concretement sur une architrecture 32-bits ou int et long font
32 bits (disons un solaris-2.[567] sur un SPARC 32-bit par exemple).
Les deux types vont avoir alors les mêmes représentations, mais ils
resteront néanmoins distincts et incompatibles. Ce n'est pas
contradictoire. C'est simplement que la sémantique C (et C++ dans une
certaine mesure) est orientée « token » et non « bits »
| > | - mais char a le meme comportement que soit signed char soit unsigned char | > Non. La norme ne dit pas ça. | | malheureusement si...
il n'y a pas de malheureusement; et j'ai mal lu ta phrase. Je l'ai comprise comme si elle voulait dire que char doit être pareil que soit 'signed char' ou 'unsigned char'.
| 6.2.5-15 | | The three types char, signed char, and unsigned char are collectively | called the character types. The implementation shall define char to | have the same range, representation, and behavior as either signed | char or unsigned char.32)
et en même temps, char doit être un type distinct.
Ce que la norme veut dire ici, c'est juste la formulation de ce qui se passe concretement sur une architrecture 32-bits ou int et long font 32 bits (disons un solaris-2.[567] sur un SPARC 32-bit par exemple).
Les deux types vont avoir alors les mêmes représentations, mais ils resteront néanmoins distincts et incompatibles. Ce n'est pas contradictoire. C'est simplement que la sémantique C (et C++ dans une certaine mesure) est orientée « token » et non « bits »
-- Gaby
Emmanuel Delahaye
In 'fr.comp.lang.c', Serge Paccalin wrote:
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas.
Mais il acceptait de générer du code. C'est un critère comme un autre.
Moi aussi, ça m'a troublé. En fait, je pense que le code est généré parce qu'il est fiable. Le warning est là pour nous rappeler qu'il s'agit d'un écart par rapport à la norme, et que la portablilité n'est pas garantie, ce qui est une Bonne Chose (c). C'est une conséquence du laxisme bien connu du langage C. Par contre en C++ ils semble que la méthode choisie soit plus radicale. C'est niet, pas de discussion! Idem pour gcc, même en C.
-- -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', Serge Paccalin <sp@mailclub.no.spam.net.invalid> wrote:
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas.
Mais il acceptait de générer du code. C'est un critère comme un autre.
Moi aussi, ça m'a troublé. En fait, je pense que le code est généré parce
qu'il est fiable. Le warning est là pour nous rappeler qu'il s'agit d'un
écart par rapport à la norme, et que la portablilité n'est pas garantie, ce
qui est une Bonne Chose (c). C'est une conséquence du laxisme bien connu du
langage C. Par contre en C++ ils semble que la méthode choisie soit plus
radicale. C'est niet, pas de discussion! Idem pour gcc, même en C.
--
-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/
| À titre d'*exemple*, Visual Studio 6.0 répond « oui » puis « non ». Je
De ce que tu m'as montré, il emettait un diagnostic dans les deux cas.
Mais il acceptait de générer du code. C'est un critère comme un autre.
Moi aussi, ça m'a troublé. En fait, je pense que le code est généré parce qu'il est fiable. Le warning est là pour nous rappeler qu'il s'agit d'un écart par rapport à la norme, et que la portablilité n'est pas garantie, ce qui est une Bonne Chose (c). C'est une conséquence du laxisme bien connu du langage C. Par contre en C++ ils semble que la méthode choisie soit plus radicale. C'est niet, pas de discussion! Idem pour gcc, même en C.
-- -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:
[...]
| écart par rapport à la norme, et que la portablilité n'est pas garantie, ce | qui est une Bonne Chose (c). C'est une conséquence du laxisme bien connu du | langage C.
Si c'est une conséquence du « laxisme bien connu du langage C », elle aurait figuré dans la norme. Or celle-ci dit explicitement et sans ambiguité que c'est no-way.
C'est plus exact de dire que c'est une extension propriétaire faite pour piéger des programmeurs.
| Par contre en C++ ils semble que la méthode choisie soit plus | radicale. C'est niet, pas de discussion! Idem pour gcc, même en C.
gcc implémente ce que dicte la définition de C.
-- Gaby
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
[...]
| écart par rapport à la norme, et que la portablilité n'est pas garantie, ce
| qui est une Bonne Chose (c). C'est une conséquence du laxisme bien connu du
| langage C.
Si c'est une conséquence du « laxisme bien connu du langage C », elle
aurait figuré dans la norme. Or celle-ci dit explicitement et sans
ambiguité que c'est no-way.
C'est plus exact de dire que c'est une extension propriétaire faite
pour piéger des programmeurs.
| Par contre en C++ ils semble que la méthode choisie soit plus
| radicale. C'est niet, pas de discussion! Idem pour gcc, même en C.
| écart par rapport à la norme, et que la portablilité n'est pas garantie, ce | qui est une Bonne Chose (c). C'est une conséquence du laxisme bien connu du | langage C.
Si c'est une conséquence du « laxisme bien connu du langage C », elle aurait figuré dans la norme. Or celle-ci dit explicitement et sans ambiguité que c'est no-way.
C'est plus exact de dire que c'est une extension propriétaire faite pour piéger des programmeurs.
| Par contre en C++ ils semble que la méthode choisie soit plus | radicale. C'est niet, pas de discussion! Idem pour gcc, même en C.
gcc implémente ce que dicte la définition de C.
-- Gaby
Erwan David
Gabriel Dos Reis écrivait :
Les deux types vont avoir alors les mêmes représentations, mais ils resteront néanmoins distincts et incompatibles. Ce n'est pas contradictoire. C'est simplement que la sémantique C (et C++ dans une certaine mesure) est orientée « token » et non « bits »
Moi je trouve aussi que c'est mieux pour la portabilité, ne serait-ce que pour ne pas avoir de problème le jour où on passe sur une archi où ce n'est plus vrai.
Dommage que cette sémantique n'ait pas été étendue au typedef...
-- Monde de merde
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait :
Les deux types vont avoir alors les mêmes représentations, mais ils
resteront néanmoins distincts et incompatibles. Ce n'est pas
contradictoire. C'est simplement que la sémantique C (et C++ dans une
certaine mesure) est orientée « token » et non « bits »
Moi je trouve aussi que c'est mieux pour la portabilité, ne serait-ce
que pour ne pas avoir de problème le jour où on passe sur une archi où
ce n'est plus vrai.
Dommage que cette sémantique n'ait pas été étendue au typedef...
Les deux types vont avoir alors les mêmes représentations, mais ils resteront néanmoins distincts et incompatibles. Ce n'est pas contradictoire. C'est simplement que la sémantique C (et C++ dans une certaine mesure) est orientée « token » et non « bits »
Moi je trouve aussi que c'est mieux pour la portabilité, ne serait-ce que pour ne pas avoir de problème le jour où on passe sur une archi où ce n'est plus vrai.
Dommage que cette sémantique n'ait pas été étendue au typedef...
