Data range - Page 1

Une variable ptr est de type unsigned char *.
Si je teste si *ptr == '­­-' (le signe "opposé", touche [(-)] et code ascii 173), ou même si *(unsigned char*)ptr == '-', GCC me lance un warning comme quoi le test est toujours faux compte tenu des bornes des valeurs possibles pour *ptr. Si je remplace le '-' par 173, plus rien. Y'a-t-il une raison logique ?

Essaye ça if (*(BYTE*)(ptr)=='-')

[EDIT] Mon truc fait la même chose, bizarre.

essaie *ptr = (unsigned char)'-'

Nan mais je cherche pas comment résoudre le problème, juste savoir pourquoi il est là

Demande directement à KK, ca ira plus vite.

euh, à tout hasard, ne serait-ce pas parce que '-' et un char et *ptr un unsigned char ?

Peut être que '­­-' doit être convertie en nombre signé, TIGCC aime bien faire ça, regarde le code produit en ASM pour avoir une certitude.

Donc char * corrige ton pb.

Bah oui l'explication ça serait ça. Mais je trouve ça étrange que gcc me warne pour une comparaison comme ça, étant donné que je vois plutot les chaines comme des unsigned char que des char

Il y a une meilleur explication, attend Kevin.

Il faut mettre *(char *)ptr == '­­-' ou (char)*ptr == '-' ou *ptr == (unsigned char)'­­-'. Les char sont signés par défaut, et ils sont promus en des int avant tout calcul, y compris ta comparaison. Donc un signed char ne peut être égal à un unsigned char que s'il est dans la plage ASCII 7-bits.

Oui donc c'est bien ça. Sachant qu'une table ASCII comporte des caractères de 0 à 255 et non pas de -128 à 127, je trouve plutot illogique que les chaines soit considérées comme [signed] char par défaut.

-funsigned-char

Oué mais c'est pas par défaut

Dommage que ce ne soit pas par défaut...

C'est pas bien grave, juste à savoir. Mais comme quoi le C n'est pas toujours parfaitement logique.

Le pbm c'est que si c'était par défaut, sa fausserait bon nombre de programme en C qui compte sur le fait que les char son "signed"....

>Mais comme quoi le C n'est pas toujours parfaitement logique.
Pour moi c'est logique vu que les shorts et longs sont eux aussi signed par défaut.
Cependant c'est vrai que le mot byte aurait été plus significatif surtout aujourd'hui ou les caractères peuvent être codé en unicode.

Uther :
>Mais comme quoi le C n'est pas toujours parfaitement logique.
Pour moi c'est logique vu que les shorts et longs sont eux aussi unsigned par défaut. Cependant c'est vrai que le mot byte aurait été plus significatif surtout aujourd'hui ou les caractères peuvent être codé en unicode.

Non short, int et long son signed !!!

Et oui le terme "char" est idiot.. byte aurait été plus significatif....

En delphi, et donc surement en pascal "normal", il me semble que c'est ça : char = [0 .. 255] et byte = [-128 .. 127], ce qui semble plus logique.

godzil> Oui bien sur c'est une erreur de ma part je voulais bien sur dire signed sinon ca aurait été en effet illogique. J'ai édité.

godzil
: Le pbm c'est que si c'était par défaut, sa fausserait bon nombre de programme en C qui compte sur le fait que les char son "signed"....

En effet, mais pire: Il y a aussi des programmes qui comptent sur le fait que les char soient unsigned. A68k par exemple. (Tu verras que j'ai mis -funsigned-char dans les FORCED_CFLAGS.) Donc je pense que la compatibilité ne soit pas la considération principale qui a porté à ce choix.

Uther :
>Mais comme quoi le C n'est pas toujours parfaitement logique. Pour moi c'est logique vu que les shorts et longs sont eux aussi signed par défaut.

Je pense que c'est plutôt ça la raison du choix.

Mais de toute façon, le standard C permet les deux choix. Un programme portable entre plusieurs compilateurs doit fonctionner quel que soit le choix du compilateur. Donc soyez contents que GCC vous permet de choisir vous-mêmes ce que vous voulez, parce qu'il n'est nullement obligé de faire ça.

Vertyos
: En delphi, et donc surement en pascal "normal", il me semble que c'est ça : char = [0 .. 255] et byte = [-128 .. 127], ce qui semble plus logique.

Tu mets dans les options du projet: -funsigned-char "-Dbyte=signed char" et tu as exactement ça.

Je sais bien tu l'as déjà dit... Mais là n'est pas la question.

La question est quoi alors? Le fait est que rien ne t'empêche à règler les options comme tu les veux, donc je ne vois pas pourquoi tu râles.

Je ne rale pas, j'explique simplement que je trouve ça illogique que les chaines soient par défaut signed (et apprement je ne suis pas le seul). Le fait qu'il existe une option pour changer ça n'a aucun rapport, je parlais de comportement par défaut.

Et ce n'est pas gravissime, je voulais juste une confirmation.

Vertyos :
Le fait qu'il existe une option pour changer ça n'a aucun rapport, je parlais de comportement par défaut.

On s'en contrefiche du comportement par défaut. Ça n'a absolument aucune importance tant qu'il y a une option pour règler le comportement qu'on veut. Le comportement par défaut de GCC est de n'optimiser rien du tout et de ne donner presque aucun avertissement. Donc l'IDE met -Os -Wall -W -Wwrite-strings quand on crée un projet, et ça ne dérange personne. Et tu peux rajouter tout ce que tu veux, par exemple -funsigned-char. Je ne vois pas du tout en quoi le comportement par défaut aurait quelle importance que ce soit.

Et personnellement, le fait que les chars soient signés par défaut m'a surpris au début, mais je trouve maintenant que c'est vraiment ce qu'il y a le plus logique. Il faut comprendre que les chars en C ne sont qu'un type d'entiers parmi d'autres, type qui "par hasard" peut contenir des caractères. Tous les autres types d'entiers sont signés si on ne précise pas unsigned, donc pourquoi char devrait-il être différent?

mais un nombre constant est considere comme signe ou non selon qu'il compare/affecte a un signe/non signe si je ne m'abuse ?

(si je m'abuse, ben #jesors#)
alors pourquoi est-ce qu'il n'y a pas le meme comportement avec les chars >

azerty83
: mais un nombre constant est considere comme signe ou non selon qu'il compare/affecte a un signe/non signe si je ne m'abuse ?

C'est faux. Pourquoi crois-tu que les suffixes u, l et ll existent?

Kevin Kofler :
On s'en contrefiche du comportement par défaut.

C'est justement tout le but du topic : non.

Je ne vois pas du tout en quoi le comportement par défaut aurait quelle importance que ce soit.

Aucune si ce n'est la logique...

Et personnellement, le fait que les chars soient signés par défaut m'a surpris au début, mais je trouve maintenant que c'est vraiment ce qu'il y a le plus logique. Il faut comprendre que les chars en C ne sont qu'un type d'entiers parmi d'autres, type qui "par hasard" peut contenir des caractères. Tous les autres types d'entiers sont signés si on ne précise pas unsigned, donc pourquoi char devrait-il être différent?

Si Delphi propose de base deux types différents, à savoir char et byte, respectivement 0 ~ 255 et -128 ~ 127, c'est bien que des gens se sont posés la question. Ça te semble peut-être logique d'avoir des caractères ascii négatifs, moi pas.

char et byte, respectivement 0 ~ 255 et -128 ~ 127

Tu t'est trompé, c'est l'inverse

Moi ca ne me semble pas plus illogique que ca. Il faut juste ce mettre dans la tete que char et un octet et pas forcément un caractère.