Subscript has type 'char' - Page 1

Quand on met un char (signé ou non) comme index pour un tableau, TIGCC rale et affiche ce warning.
Alors qu'il suffit de faire un typecasting sur ce char pour enlever le warning. Mais surtout je ne comprends pas à quoi sert ce warning, si on met un char comme index de tableau c'est volontaire non ?

P.S, surtout pour Kevin : La question n'est pas "comment enlever ce warning", je me doute bien qu'il y a un switch, mais simplement quelle est la raison de ce message ?

ben, les indices de tableau doivent être de type int, c tout
(ou short sur ti, vu que (avec les régléages pr défaut !!!), short a la même taile que int)
ce, je suppose, parce que int représente la taille d'un mot-machine... et que c'est (je suppose) ce qui est utilisé pour les adressages, ou quelque chose dans ce style.

enfin, le truc, c qu'il fo un int

Tu ne devrais pas avoir de warning avec un unsigned char normalement.
GCC donne un warning pour les chars signés utilisés comme indices, parce que le risque de tomber sur un indice négatif (et donc incorrect) est très grand.

Mouais... Tu m'as plus embrouillé qu'autre chose là

Regarde: Imagine par exemple que tu aies un tableau qui pour chaque caractère d'un jeu de caractères de 8 bits (celui de la TI-89 par exemple) te donne la largeur de ce caractère:
int largeurs[256];

Imagine maintenant que tu essayes de déterminer la taille d'une chaîne de caractères de la manière suivante:
const char *s="Hello, world!", *p;
int l=0;
for (p=s;*p;p++) l+=largeurs[*p];
C'est une grave erreur, parce que si le caractère en p est >128 et si *p est signé, *p est négatif!

Solution:
const unsigned char *s="Hello, world!", *p;
int l=0;
for (p=s;*p;p++) l+=largeurs[*p];
ou:
const char *s="Hello, world!", *p;
int l=0;
for (p=s;*p;p++) l+=largeurs[(unsigned char)*p];

C'est pour ça que GCC te donne un warning.

Le problème est que mon char est non-signé justement... Et le warning apparait quand même.
Je me doutais un peu que c'était une mesure de précaution, mais selon moi quand on met un char en index, on sait ce qu'on fait et pourquoi on le fait.

[verification]

Arf non j'avais tors... Le char était signé. Mais bon pour moi ça revient au même, si j'ai mit un char c'est parcequ'il n'avait aucun risque de passer au-dessus de 127 (sa valeur maximum est 99).

Oui, mais il peut passer en dessous de 0 !
c'est pour ça que tu as ce WARNING.
Mets-le en unsigned, je vois pas où est le pb...

Ou sinon, tu ignores ou désactives (-Wno-char-subscripts) le warning. Mais la solution propre est de mettre le char en non signé.

Et la justification des développeurs de GCC pour ce warning est:

-Wchar-subscripts Warn if an array subscript has type char. This is a common cause of error, as programmers often forget that this type is signed on some machines.

(citation du manuel de GCC dans la documentation de TIGCC).

Petite précision, le signage auto / nonsignage auto (quand on précise pas quoi) dépend du compilateur !

Genre GCC ta 2 options genre --unsigned --signed (faut voir la doc je conné po par coeur, j'utilise jamais ses fonction la)

-funsigned-char (ou -fno-signed char) et -fsigned-char (ou -fno-unsigned-char).

C'est sale de se reposer sur les options du compilateur. Ca peut conduire à de gros problèmes si quelqu'un qui recompile le programme n'utilise pas les mêmes options (par exemple, l'utilisation du type 'int' est à proscrire à cause du switch -mlong)...

C'est pour ça qu'il faut distribuer au moins un parmi:
* un fichier .tpr
* un fichier .bat
* un makefile

Si on fait ça, je ne vois pas le problème avec l'utilisation d'options du compilateur. (Par exemple, Backgammon présuppose -std=gnu99.)

jackiechan a écrit :
Oui, mais il peut passer en dessous de 0 !
c'est pour ça que tu as ce WARNING. Mets-le en unsigned, je vois pas où est le pb...

Moi non plus, je l'ai passé en unsigned, mais ça n'était pas la peine, j'ai fait ça uniquement pour ne plus avoir le warning.

> C'est pour ça qu'il faut distribuer au moins un parmi:
> * un fichier .tpr
> * un fichier .bat
> * un makefile

Bien sûr. Mais ce n'est pas tout le monde qui le fait...

En effet, ce n'est pas une bonne idée de donner des sources sans aucune instruction de compilation, surtout si des options particulières sont nécessaires.

reste la solution de ne pas distribuer les sources

Mais il vaut toujours mieux des sources difficiles à compiler que pas de sources du tout.

chacun son point de vue...

Squale je croyais que t'étais pour l'open-source...

je ne suis pas contre...
cela dit, je ne diffuse pas les sources de mes gros programmes
(les petits, je veux bien... (que ce soit dans le monde TI, ou ailleurs), mais les gros... je n'ai encore jamais distribuée de sources d'un prog que je juge gros))

Et pourquoi cela?
Je ne vois pas de désavantage à distribuer les sources... à part peut-être d'avoir peur que quelqu'un rigole devant ses sources. Mais ça apporte plusieurs avantages:
- Si un jour le programme ne marche plus pour des causes de compatibilité et que tu ne fais plus parti de la communauté (genre AMS 3.xx), on pourra reprendre les algos et le code, et changer les erreurs dûes à la compatibilité.
- Une personne peut apprendre beaucoup de choses de tes sources.
- Quelqu'un peut aussi changer certaines choses qui ne lui plaisent pas, et c'est toujours interessant. (Je l'ai fait moi-même pour un jeu et c'est vraiment pratique)

Enfin ça m'étonnerais que tu changes d'avis, tu as du y réfléchir, mais bon, c'est pas parce que tu n'as jamais distribué les sources d'un gros prog qu'il ne faut pas le faire.

Une personne peut apprendre beaucoup de choses de tes sources

Possible...
Notament pour les sources pas trops longs => c pour cela, entre autre, que ça me géne pas de distribuer des sources de petite taille (qd je dis petite taille, ça veut pas dire 50 lignes !)
cela dit, les sources de gdes taille sont rarement simple à comprendre pour un débuttant (et même pr un non-débuttant), et ne sont donc pas idéaux pour apprendre

à part peut-être d'avoir peur que quelqu'un rigole devant ses sources

Peut-être que quelques uns rigoleraient... cela dit, la majorité des gens qui ont vu de mes sources assez importantes n'ont pas rigolé
("tu as fait ça en un week-end ?" "heu... dans l'écran des crédits, tu peux presque enlever nos noms et laisser que le tien" )

Quelqu'un peut aussi changer certaines choses qui ne lui plaisent pas, et c'est toujours interessant

Possible... je l'ai moi-même déjà fait pour certains programmes.
Cela dit, jamais pr des trops gros, et assez rarement : soit j'aime, soit je repart de 0, en général.

changer les erreurs dûes à la compatibilité

C la chose qui m'a pdt pas mal d temps fait hésiter...

Enfin ça m'étonnerais que tu changes d'avis, tu as du y réfléchir

J'y ai pas mal réfléchi, en effet... et pour ce qui touche aux TI, je ne penses pas changer d'avis...
Pour la prog sur PC, ma fois, je n'y ai pas encore assez réfléchi.

J'ai aussi modifié un certain nombre de sources de programmes de TICT, ou du moins suggéré des modifications à Tom.

Les gros programmes en pur ASM ne sont pas très faciles à comprendre, même pour un programmeur confirmé, si le source est peu/pas commenté.
Les gros programmes en C, sont plutôt plus faciles à comprendre, qu'ils soient commentés ou non (mais il vaut mieux qu'ils soient bien commentés ).

gros prog en C facilement compréhensibles > pour un programmeur confirmé, oui...
Mais pour un débuttant, j'en doute...

Meme pour un programmeur confirmé c'est pas forcement evident ...
Les sources de Total sont distrubuées, mais je sais qu'elles sont très crades et a peu près incompréensibles ...

Mouais, les sources que tu as distribuées sont celles de la version 0.5 ou par là. Donc l'état d'avancement n'est pas grandiose.
Tu ne voudrais pas nous passer les sources les plus récentes ? (sauf si tu bosses toujours dessus...)

"plutôt plus faciles à comprendre" =/= "facilement compréhensibles" !

Bien entendu, un débutant aura du mal à comprendre un gros programme en C, même bien commenté. Ca peut même être difficile pour un programmeur confirmé.
Mais ça n'est rien par rapport aux difficultés qu'un débutant aura à comprendre un gros programme en ASM, même bien commenté.

je suis mal placé r parler de l'ASM...