Position sous-chaine

Gabriel Dos Reis

05/08/2003 à 17:13

Francois Cartegnie writes:

| Francois Cartegnie wrote:
| >> Mais le type est différent. Cependant, je pense qu'en C, ça ne
| >> méritait qu'un warning.
| > mais l'erreur donnée n'est pas une erreur de typage.
| >
| >>> forçant en unsigned char avant la soustraction.
| >>
| >>
| >>
| >> 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...
| >
|
| 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.

-- Gaby

Vincent Lefevre

05/08/2003 à 17:14

Dans l'article ,
Emmanuel Delahaye écrit:

In 'fr.comp.lang.c', Francois Cartegnie wrote:

argh.. j'ai trouvé. j'ai un unsigned char * et un char * .
Ca me donne pas la raison de l'erreur, etant donné qu'ils sont
codés sur le même nb de bits et que j'avais aussi essayé de
soustraire en les

Mais le type est différent. Cependant, je pense qu'en C, ça ne
méritait qu'un warning.

Pour la cohésion du langage, je ne pense pas... sauf si tu arrives
à donner un sens à une différence de deux pointeurs sur des objets
de types différents dans le cas général.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Emmanuel Delahaye

05/08/2003 à 17:17

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.

--
-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/

Erwan David

05/08/2003 à 17:23

"Ivan Vecerina" écrivait :

Maintenant, certes, on peut choisir de s'en tenir a un seul languages.
Mais de la a traiter d'ignorants ceux qui ont l'esprit plus ouvert ?

Est-ce avoir l'esprit plus ouvert que d'imposer à ceux qui n'en ont
rien à foutre des contraintes supplémentaires ?

--
Monde de merde

Richard Delorme

05/08/2003 à 17:25

invalid operands to binary -

Peux tu poster le code /exact/ et complet (réduit au minimum) qui donne
le défaut que tu signales?

argh.. j'ai trouvé. j'ai un unsigned char * et un char * .
Ca me donne pas la raison de l'erreur, etant donné qu'ils sont codés sur
le même nb de bits et que j'avais aussi essayé de soustraire en les
forçant en unsigned char avant la soustraction.

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

--
Richard

Ivan Vecerina

05/08/2003 à 17:38

"Erwan David" wrote in message
news:
| "Ivan Vecerina" écrivait :
|
| > Maintenant, certes, on peut choisir de s'en tenir a un seul languages.
| > Mais de la a traiter d'ignorants ceux qui ont l'esprit plus ouvert ?
|
| Est-ce avoir l'esprit plus ouvert que d'imposer à ceux qui n'en ont
| rien à foutre des contraintes supplémentaires ?

Dis-moi, quelle contrainte ai-je cherché à imposer ?

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

Ben voilà, je sombre dans le cynisme maintenant...

Amicalement,
Ivan

Emmanuel Delahaye

05/08/2003 à 17:40

In 'fr.comp.lang.c', Francois Cartegnie wrote:

Pour exemple, ce code passe pas a la compilation et génère un
" invalid operands to binary - "
au lieu d'un warning.

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <string.h>

main(int argc, char* argv)
{

char * a; unsigned char * b;
b = strstr(a, "truc");
int size = b - a;
}

main.c:7: warning: return type defaults to `int'
main.c:7: warning: second argument of `main' should be `char **'

main.c: In function `main':
main.c:11: invalid operands to binary -
main.c:11: warning: unused variable `size'

main.c:6: warning: unused parameter `argc'
main.c:6: warning: unused parameter `argv'

Ok, si tu postais du code clair, ça aiderait!

#include <string.h>
#include <stdio.h>
#include <stddef.h>

int main(void)
{
char *a = "C'est quoi ce truc ?";
char unsigned *b;

b = strstr(a, "truc");

if (b != NULL)
{
ptrdiff_t size = b - a;

printf ("size =%dn", size);
}

return 0;
}

main.c:15: invalid operands to binary -

Effectivement il y a un problème. En gros ça signifie "opérandes invalides
dans le binaire". Ce n'est pas à proprement parler une erreur de compilation,
mais plutôt de traduction de l'assembleur en binaire. Le code assembleur
produit par gcc 3.2.x serait buggé. C'est possible. Que la cause en soit un
problème de disparité entre pointeur char* et unsigned char*, c'est possible
aussi. Mais ce défaut n'apparait pas sur un autre compilateur (Borland C 3.1,
par exemple).

Compiling MAIN.C:
Warning MAIN.C 10: Mixing pointers to signed and unsigned char
Warning MAIN.C 14: Mixing pointers to signed and unsigned char
Linking EXEPROJ.EXE:

Comme je l'avais prévu, il y a des warnings, mais le résultat est correct.

D:CLCCCATREGNI>bc proj.prj
size

Ceci-dit, il n'est pas bon de mélanger des objets signés et non signés.

Résultat des courses, on dirait qu'il y a un bug dans gcc. Si quelqu'un peut
faire une contre manip avec un vieux gcc 2.95... qu'on voit si c'est une
régression...

--
-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', Francois Cartegnie <NOSPAM@TAMAMAN.OWC> wrote:

Pour exemple, ce code passe pas a la compilation et génère un
" invalid operands to binary - "
au lieu d'un warning.

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <string.h>

main(int argc, char* argv)
{

char * a; unsigned char * b;
b = strstr(a, "truc");
int size = b - a;
}

main.c:7: warning: return type defaults to `int'
main.c:7: warning: second argument of `main' should be `char **'

main.c: In function `main':
main.c:11: invalid operands to binary -
main.c:11: warning: unused variable `size'

main.c:6: warning: unused parameter `argc'
main.c:6: warning: unused parameter `argv'

Ok, si tu postais du code clair, ça aiderait!

#include <string.h>
#include <stdio.h>
#include <stddef.h>

int main(void)
{
char *a = "C'est quoi ce truc ?";
char unsigned *b;

b = strstr(a, "truc");

if (b != NULL)
{
ptrdiff_t size = b - a;

printf ("size =%dn", size);
}

return 0;
}

main.c:15: invalid operands to binary -

Effectivement il y a un problème. En gros ça signifie "opérandes invalides
dans le binaire". Ce n'est pas à proprement parler une erreur de compilation,
mais plutôt de traduction de l'assembleur en binaire. Le code assembleur
produit par gcc 3.2.x serait buggé. C'est possible. Que la cause en soit un
problème de disparité entre pointeur char* et unsigned char*, c'est possible
aussi. Mais ce défaut n'apparait pas sur un autre compilateur (Borland C 3.1,
par exemple).

Compiling MAIN.C:
Warning MAIN.C 10: Mixing pointers to signed and unsigned char
Warning MAIN.C 14: Mixing pointers to signed and unsigned char
Linking EXEPROJ.EXE:

Comme je l'avais prévu, il y a des warnings, mais le résultat est correct.

D:CLCCCATREGNI>bc proj.prj
size

Ceci-dit, il n'est pas bon de mélanger des objets signés et non signés.

Résultat des courses, on dirait qu'il y a un bug dans gcc. Si quelqu'un peut
faire une contre manip avec un vieux gcc 2.95... qu'on voit si c'est une
régression...

--
-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/

Vous avez filtré cet utilisateur ! Consultez son message

In 'fr.comp.lang.c', Francois Cartegnie wrote:

Pour exemple, ce code passe pas a la compilation et génère un
" invalid operands to binary - "
au lieu d'un warning.

#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <string.h>

main(int argc, char* argv)
{

char * a; unsigned char * b;
b = strstr(a, "truc");
int size = b - a;
}

main.c:7: warning: return type defaults to `int'
main.c:7: warning: second argument of `main' should be `char **'

main.c: In function `main':
main.c:11: invalid operands to binary -
main.c:11: warning: unused variable `size'

main.c:6: warning: unused parameter `argc'
main.c:6: warning: unused parameter `argv'

Ok, si tu postais du code clair, ça aiderait!

#include <string.h>
#include <stdio.h>
#include <stddef.h>

int main(void)
{
char *a = "C'est quoi ce truc ?";
char unsigned *b;

b = strstr(a, "truc");

if (b != NULL)
{
ptrdiff_t size = b - a;

printf ("size =%dn", size);
}

return 0;
}

main.c:15: invalid operands to binary -

Effectivement il y a un problème. En gros ça signifie "opérandes invalides
dans le binaire". Ce n'est pas à proprement parler une erreur de compilation,
mais plutôt de traduction de l'assembleur en binaire. Le code assembleur
produit par gcc 3.2.x serait buggé. C'est possible. Que la cause en soit un
problème de disparité entre pointeur char* et unsigned char*, c'est possible
aussi. Mais ce défaut n'apparait pas sur un autre compilateur (Borland C 3.1,
par exemple).

Compiling MAIN.C:
Warning MAIN.C 10: Mixing pointers to signed and unsigned char
Warning MAIN.C 14: Mixing pointers to signed and unsigned char
Linking EXEPROJ.EXE:

Comme je l'avais prévu, il y a des warnings, mais le résultat est correct.

D:CLCCCATREGNI>bc proj.prj
size

Ceci-dit, il n'est pas bon de mélanger des objets signés et non signés.

Résultat des courses, on dirait qu'il y a un bug dans gcc. Si quelqu'un peut
faire une contre manip avec un vieux gcc 2.95... qu'on voit si c'est une
régression...

--
-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/

Emmanuel Delahaye

05/08/2003 à 17:42

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.

--
-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/

Emmanuel Delahaye

05/08/2003 à 17:44

In 'fr.comp.lang.c', Serge Paccalin wrote:

| 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* ?

SPN>cl -nologo -W4 charuchar.c
charuchar.c
charuchar.c(8) : warning C4057: '-' : 'char *' differs in indirection to
slightly different base types from 'unsigned char *'

SPN>cl -nologo -W4 charuchar.cpp
charuchar.cpp
charuchar.cpp(7) : error C2230: '-' : indirection to different types

Tout à fait. Mais certains visiblement ne savent pas encore faire la
différence entre C et 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/

Vincent Lefevre

05/08/2003 à 17:50

Dans l'article ,
Emmanuel Delahaye écrit:

#include <string.h>
#include <stdio.h>
#include <stddef.h>

int main(void)
{
char *a = "C'est quoi ce truc ?";
char unsigned *b;

b = strstr(a, "truc");

if (b != NULL)
{
ptrdiff_t size = b - a;

printf ("size =%dn", size);
}

return 0;
}

main.c:15: invalid operands to binary -

Effectivement il y a un problème. En gros ça signifie "opérandes
invalides dans le binaire". Ce n'est pas à proprement parler une
erreur de compilation, mais plutôt de traduction de l'assembleur en
binaire.

Quoi?????

Le code assembleur produit par gcc 3.2.x serait buggé. C'est
possible. Que la cause en soit un problème de disparité entre
pointeur char* et unsigned char*, c'est possible aussi. Mais ce
défaut n'apparait pas sur un autre compilateur (Borland C 3.1, par
exemple).

Compiling MAIN.C:
Warning MAIN.C 10: Mixing pointers to signed and unsigned char
Warning MAIN.C 14: Mixing pointers to signed and unsigned char
Linking EXEPROJ.EXE:

Comme je l'avais prévu, il y a des warnings, mais le résultat est correct.

Que ce soit un warning ou une erreur (qui sont des notions inconnues
de la norme), c'est dans les deux cas un diagnostique (ce qui est
requis par la norme?).

D:CLCCCATREGNI>bc proj.prj
size

Ceci-dit, il n'est pas bon de mélanger des objets signés et non signés.

Résultat des courses, on dirait qu'il y a un bug dans gcc.

Moi je dis que non.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Position sous-chaine

10 réponses

Veuillez sélectionner un problème