Discussion :

[chocolat88]

bonjour,

EOF une constante symbolique qui vaut -1, or si dans le buffer j'ai -1 avant d'arriver à la fin du buffer, il ne sera pas entièrement vider ?

[Sve@r]

bonjour,

EOF une constante symbolique qui vaut -1, or si dans le buffer j'ai -1 avant d'arriver à la fin du buffer, il ne sera pas entièrement vider ?

Bonjour

Pour répondre à ta question, il ne faut pas confondre l'int -1 (0xffff) et le caractère -1 (0x00ff). C'est pour ça qu'on déclare "c" comme int et non comme char. Et question orthographe, avec cette tournure de phrase c'est "vidé" au participe passé et non "vider" à l'infinitif.

[chrtophe]

La valeur réelle de EOF est un nombre négatif, dépendante du système d'exploitation, communément -1.

Attention, ne considères pas que EOF vaut -1, mais EOF

getchar travaille avec stdin, tu ne récupèreras que les valeurs des touches de ton clavier éventuellement les touches "-" et "1" si tu tapes -1, donc 2 caractères. La touche 1 donnera la valeur 49, code ASCII de la touche 1, si tu l'interprètes comme un int, et vaudra '1' si tu l'interprètes comme un char.

Et pour l'éventuel cas ou stdin a été redirigé,depuis un fichier, les valeurs récupérées seront considérés comme des chars. si tu regardes n'importe quel fichier avec un éditeur hexadécimal, tu ne verras que des valeurs entre 0 et 255.

Si on postule qu'un int est codé sur un octet (ce qui n'est plus le cas, mais simplifiera la compréhension):
Si tu est en unsigned int tu pourra avoir les valeurs de -128 à +127, en signed int, tu pourras avoir les valeurs 0 à 255. C'est ce qu'on appelle l'arithmétique signée. Un octet lu depuis un flux et devant être placé dans un int d'un octet pourra donc avoir une valeur positive ou négative si il est lu comme un nombre, mais il est logique qu’en cas d'un char, ce ne soit qu'une valeur positive.

[Sve@r]

Attention, ne considères pas que EOF vaut -1, mais EOF

Sa question reste valable quelle que soit la valeur assignée à EOF...

Si tu est en unsigned int tu pourra avoir les valeurs de -128 à +127, en signed int, tu pourras avoir les valeurs 0 à 255. C'est ce qu'on appelle l'arithmétique signée. Un octet lu depuis un flux et devant être placé dans un int d'un octet pourra donc avoir une valeur positive ou négative si il est lu comme un nombre, mais il est logique qu’en cas d'un char, ce ne soit qu'une valeur positive.

T'as inversé signed/unsigned mais c'est pas grave. Ce qui m'embête dans ce que tu dis c'est que je ne suis pas d'accord. Déjà parce que char sans précision c'est signed par défaut.

Mais surtout le sujet de cette question n'est pas tant la valeur décimale qui s'affichera si on affiche l'octet lu mais la comparaison que fera le C dans un test while (c != -1) (je mets "-1" pour simplifier). Parce que si "c" est unsigned, alors le test n'échouera jamais (parce que même si "c" récupère le -1 (0xff) renvoyé par getchar() quand elle ne lit plus rien, en unsigned ça vaut 255 et 255 est malheureusement différent de -1) et c'est boucle infinie. Et si "c" est signed, alors ok la boucle a des chances de quitter.
Mais si "c" est char et qu'il récupère du fichier l'octet 0xff, alors là le test passera faux "par accident" (parce que dans ce cas, lors de l'évaluation c != -1, le "-1" est lui-aussi casté en char) et on quitte avant d'avoir fini.

Donc en fait le sujet n'est pas tout à fait dans la caractéristique signed/unsigned (ok ça joue car en unsigned de toute façon le programme part en torche mais personne n'en avait parlé jusqu'à présent) mais surtout dans le fait de positionner "c" en tant qu'int pour que dans le cas où il récupère un 0xff depuis le fichier, sa valeur sera alors 0x00ff (donc là 255 que ce soit en signed ou en unsigned ça ne change pas) et ne sera pas égale à 0xffff. Et donc là, la boucle ne quittera pas "par erreur".

[Médinoc]

Ce que la norme dit sur EOF, c'est que c'est un int et que c'est négatif.
Et donc, hors du domaine des unsigned char (représentant au moins 0 à 255 et forcément non-négatif) converti en int et retourné par fgetc() et par extension getc() et getchar().

Là où on serait en droit de se poser des questions, ce serait pour une plate-forme où sizeof(char)==sizeof(int)... (la bonne nouvelle, c'est que 0xFFFF et 0xFFFFFFFF ne sont pas des caractères Unicode valides)

[Bktero]

Déjà parce que char sans précision c'est signed par défaut.

Il n'y a pas de garantie quant au fait que char soit signé ou non. Ca dépend de l'implémentation. C'est le seul type entier pour lequel le signed n'est pas implicite. D'ailleurs, char, signed char et unsigned char sont 3 types différents.

Voir cette question stackoverflow et notamment la réponse acceptée :

The signedness of a char that isn't either a signed char or unsigned char is implementation-defined. Many systems make it signed to match other types that are signed by default (like int), but it may be unsigned on some systems.

Ou alors cette question et sa réponse acceptée :

The standard does not specify if plain char is signed or unsigned.

In fact, the standard defines three distinct types: char, signed char and unsigned char.