SDL, scanf, chaine, marche mais warning

Version imprimable

Bonjour a tous et à toutes.

J'utilise code BLOCKS comme compilateur, seulement mon compilo m'indique un warning que je ne sais pas corriger.

warning: array subscript has type 'char'

Et voici la ligne ou il y a dit bug.
Code:

1 2 3 4 5 else if(event.key.keysym.unicode >= 'A' && event.key.keysym.unicode <= 'z') { perso.pseudo[i] = (char)event.key.keysym.unicode;/*ICI*/ i++; }
Cordialement qnop

11/08/2010, 23h17
Obsidian

Citation:

Envoyé par qnop

Bonjour a tous et à toutes.

J'utilise code BLOCKS comme compilateur, seulement mon compilo m'indique un warning que je ne sais pas corriger.

warning: array subscript has type 'char'

Ça veut dire « attention : l'indice du tableau a le type "char" ».

Tu as probablement déclaré « i » comme étant un char plutôt qu'un int. Ce n'est pas interdit, parce qu'un char est en soi un nombre entier et que le transtypage se fait tout seul, mais tu risques d'arriver assez vite à court de place pour tes pseudos (après le 128ème).
23/11/2010, 14h31
troumad

Citation:

Envoyé par Obsidian

Ça veut dire « attention : l'indice du tableau a le type "char" ».

C'est la traduction google ça...
Je pense plutôt à attention, le tableau contient des char !

Si je défini mon tableau comme des unsigned char, pour

Code:

strcmp(action_name,"_3D6")

j'ai comme avertissement :

Code:

attention : pointer targets in passing argument 1 of ‘strcmp’ differ in signedness

et je n'ai pas les avertissement de la forme :

Code:

attention : array subscript has type ‘char’|

pour

Code:

action_name[pl_num]>'0'

Par contre, si je transforme le tableau en char (ou gchar), c'est l'inverse.

Pour ne plus avoir d'erreur, je dois mettre :

Code:

*(action_name+pl_num)>'0'

et initialiser mon pointeur en (g)char * .

Pourquoi ces manipulations sont-elles nécessaire pour éviter les warnings ? Je n'en sais rien !
23/11/2010, 15h49
Obsidian
Citation:

Envoyé par troumad

C'est la traduction google ça...
Je pense plutôt à attention, le tableau contient des char !

Absolument pas. Relis bien.

« Array subscript » : l'indice du tableau ;
« has type 'char' » : a le type 'char' ;

Citation:

Si je défini mon tableau comme des unsigned char, pour

Code:

strcmp(action_name,"_3D6")

j'ai comme avertissement :

Code:

attention : pointer targets in passing argument 1 of ‘strcmp’ differ in signedness

Ce qui signifie littéralement « Les cibles des pointeurs au passage de l'argument 1 de "strcmp" diffèrent en signe. ». C'est parce que tu passes des « unsigned char » là où le compilo attend des « char », qu'il considère implicitement comme signés.

Citation:

et je n'ai pas les avertissement de la forme :

Code:

attention : array subscript has type ‘char’|

pour

Code:

action_name[pl_num]>'0'

C'est parce que ce n'est pas la même erreur et qu'elle ne concerne pas la même chose. Là encore, c'est la variable passée en indice de son tableau qui est concernée. Pas le contenu du tableau proprement dit. Le compilo se plaint parce qu'un « numéro de case » (l'indice du tableau) doit être de type int (sans préciser si c'est signé ou non) et que l'indice en question est un char.

De toutes façons, c'est très facile à reproduire :
Code:

1 2 3 4 5 6 7 8 int main (void) { char i = 2; char tab[50]; tab[i] = 'a'; return 0; }
Code:

1 2 3 $ gcc tableau.c -o tableau -Wall tableau.c: In function ‘main’: tableau.c:6: attention : array subscript has type ‘char’
23/11/2010, 16h06
troumad

Gagné !

Code:

action_name[(int)pl_num]>'0'

ne sort pas d'erreur !

:merci:

Code:

action_name[(unsigned short)pl_num]>'0'

non plus. Je ne pensais pas le type de l'indice était si important ! Un char me convient tout à fait d'un point de vu logique.
23/11/2010, 17h55
Obsidian
Citation:

Code:

action_name[(unsigned short)pl_num]>'0'

non plus. Je ne pensais pas le type de l'indice était si important ! Un char me convient tout à fait d'un point de vu logique.

Tout dépend de ce que tu entends par « d'un point de vue logique », bien sûr, mais peut-être fais-tu le raccourci « char = entier de 8 bits de large ».

D'abord, cette dernière hypothèse n'est pas du tout garantie pas la norme qui, elle, précise qu'un char est un entier suffisamment large pour recevoir un caractère du jeu de base sur la plate-forme cible. Certaines architectures (les PIC 12xxxx, par exemple) ne manipulent pas forcément des mots de 8 bits.

Ensuite, d'un point de vue sémantique, un « char » est un caractère et un « int » est un nombre entier. Et le numéro de rang d'un élément dans un tableau est forcément — en lui-même — un nombre entier. C'est pour des raisons techniques qu'un caractère en langage C est lui-même représenté par son rang dans une table et que sa représentation est donc un nombre entier.

On peut mettre tout cela en évidence assez facilement. Si l'indice d'un tableau peut légalement être un char, on doit pouvoir écrire des choses de ce genre :
Code:

1 2 3 char tab[256]; tab['A'] = 1;
Cela n'est légitime que si tu gères une table de traduction dans laquelle la donnée à lire ou à mettre à jour est bien en rapport avec le caractère « A ». Sinon, l'expression en elle-même n'est pas déterministe, car elle dépend du jeu de caractères de la plate-forme cible.

En plus, si int est fait pour gérer les entiers « ordinaires », bien souvent, un char sera trop petit pour indexer le tableau entier.
23/11/2010, 18h50
troumad

Citation:

Envoyé par Obsidian

D'abord, cette dernière hypothèse n'est pas du tout garantie pas la norme qui, elle, précise qu'un char est un entier suffisamment large pour recevoir un caractère du jeu de base sur la plate-forme cible. Certaines architectures (les PIC 12xxxx, par exemple) ne manipulent pas forcément des mots de 8 bits.

La norme dit que un char doit être en 0 et 127, un signed char entre -127 et +127 (bien que en pratique, ce soit souvent entre -128 et +127) et un unsigned char entre 0 et 255. SI on a à indexer un tableau jusqu'à 127, un char est suffisant.

Le problème est l'indice en char, si je le mets unsigned char, je n'ai plus de problème.
23/11/2010, 20h05
Obsidian

Citation:

Envoyé par troumad

La norme dit que un char doit être en 0 et 127, un signed char entre -127 et +127 (bien que en pratique, ce soit souvent entre -128 et +127) et un unsigned char entre 0 et 255. SI on a à indexer un tableau jusqu'à 127, un char est suffisant.

La norme dit qu'un caractère du jeu d'exécution de base stocké dans un char est garanti d'être positif et que les autres caractères dépendent de l'implémentation (on rappelle qu'un char est un entier assez gros pour contenir le code d'un caractère du jeu de base, mais que rien ne l'empêche d'en contenir d'autres).

Elle garantit par ailleurs des plages minimum pour chaque type, mais qui peuvent être adaptées (donc étendues) à l'architecture-cible. Rien n'interdit de définir tous les types entiers, char compris, sur 64 bits, par exemple.

Citation:

Le problème est l'indice en char, si je le mets unsigned char, je n'ai plus de problème.

C'est encore plus subtil : si tu mets « signed char » à la place de char tout court, tu n'auras pas non plus d'avertissement de la part de GCC. C'est dû à un détail de la norme, qui commence par définir « char » comme on l'a dit, puis qui définit les entiers, et qui inclut « signed char » comme étant un entier occupant la même place que « char ». Elle déclare ensuite que tout entier signé a un pendant non signé.

Donc, « char » et « signed char » sont tous les deux des entiers signés définis sur le même nombre de bits, quel qu'il soit. Ce sont donc les mêmes types, fonctionnant de la même façon, mais le premier est officiellement désigné comme le container d'un caractère, tandis que le second est considéré comme un entier numérique.

Tiré du dernier draft (« n1256.pdf ») :

Citation:

Envoyé par Norme C ISO/IEC 9899:TC3 WG14/N1256

6.2.5 Types

[…]

3 An object declared as type char is large enough to store any member of the basic execution character set. If a member of the basic execution character set is stored in a char object, its value is guaranteed to be nonnegative. If any other character is stored in a char object, the resulting value is implementation-defined but shall be within the range of values that can be represented in that type.

4 There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. (These and other types may be designated in several additional ways, as described in 6.7.2.) There may also be implementation-defined extended signed integer types.28) The standard and extended signed integer types are collectively called signed integer types.29)

5 An object declared as type signed char occupies the same amount of storage as a ‘‘plain’’ char object. A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

6 For each of the signed integer types, there is a corresponding (but different) unsigned integer type (designated with the keyword unsigned) that uses the same amount of storage (including sign information) and has the same alignment requirements. The type _Bool and the unsigned integer types that correspond to the standard signed integer types are the standard unsigned integer types. The unsigned integer types that correspond to the extended signed integer types are the extended unsigned integer types. The standard and extended unsigned integer types are collectively called unsigned integer types.30)

[…]

5.2.4.2.1 Sizes of integer types <limits.h>

1 The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives. Moreover, except for CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions that have the same type as would an expression that is an object of the corresponding type converted according to the integer promotions. Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign
.
— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
— minimum value for an object of type signed char
-127 // −(27 − 1)
SCHAR_MIN
— maximum value for an object of type signed char
+127 // 27 − 1
SCHAR_MAX
— maximum value for an object of type unsigned char
255 // 28 − 1
UCHAR_MAX
— minimum value for an object of type char
see below
CHAR_MIN
— maximum value for an object of type char
see below
CHAR_MAX
see below

[…]

2 If the value of an object of type char is treated as a signed integer when used in an
expression, the value of CHAR_MIN shall be the same as that of SCHAR_MIN and the value of CHAR_MAX shall be the same as that of SCHAR_MAX. Otherwise, the value of CHAR_MIN shall be 0 and the value of CHAR_MAX shall be the same as that of UCHAR_MAX.15) The value UCHAR_MAX shall equal 2CHAR_BIT − 1.

On note que le dernier paragraphe n'est qu'une manière formelle de décrire ce qui se passe lorsque l'on tient compte ou non du bit de signe dans un registre entier binaire.
23/11/2010, 21h47
troumad

L'anglais est une langue que je maîtrise peu :oops:
Ça ne rend pas du tout la recherche sur internet facile sur les sujets pointus de l'informatique :?

Enfin... J'ai du comprendre des choses... Je vois qu'on y parle de int, long int, and long long int mais sans donner leur taille (en octet ou en bite). On y parle pas de long ou long long qui selon moi étaient stockés sur 32 ou 64 bits. Le short l'étant sur 16 et le char sur 8 (au moins dans les environnement Linux/Windows sur PC).