bonjour

je programme sur un micro controlleur, processeur : ARMv7 Processor rev 4 (v7l)

dans mon programme j'initialise une variable caractere de type char pour lire caractere par caractere un fichier ascii.

sauf qu'a la compilation j'ai ce warning :

comparison is always true due to limited range of data type

et a l'execution ca lit n'importe quoi.

mais si je remplace le type char par le type int8_t, ça marche sans probleme.

pourquoi ? je croyais que c'etait un equivalent c'est 2 types.

et pourquoi ca pose un probleme le type char ?

Sans le code source, que dire?

effectivement tu pourrais au moins nous donner la ligne ou ça bug

mais  ce n'est pas du au code, mais surement du au processeur, mais je ne comprends pas pourquoi.

un code tout simple qui ne marche pas.

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

int main()
{
    char c;

    FILE *f = fopen("test.txt", "r");
    while((c = fgetc(f)) != EOF)
        printf("%c", c);

    return 0;
}

le meme code qui marche en remplacant char par int8_t :

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int main()
{
    int8_t c;

    FILE *f = fopen("test.txt", "r");
    while((c = fgetc(f)) != EOF)
        printf("%c", c);

    return 0;
}

le premier code la boucle while ne s'arrete jamais et lorsque je le compile j'ai le warning :

 warning: comparison is always true due to limited range of data type [-Wtype-limits]
     while((c = fgetc(f)) != EOF)

-
Edité par Luzwitz 25 avril 2019 à 10:38:07

La fonction fgetc retourne un int et non un char. Avant de dire que ce n'est pas dû au code, il faut d'abord se dire que le problème vient de ton code et ensuite seulement tu peux dire que le problème vient de ton code. Dans de rare cas, le problème vient du processeur... et si le problème vient du processeur, ce n'est pas le compileur qui te donnerait un warning, tu aurais une erreur d'exécution.

-
Edité par Pouet_forever 25 avril 2019 à 11:51:53

a oui autant pour moi.

et alors pourquoi quand je le compile sur mon ordinateur il n'y a pas d'erreur et quand je l'éxécute ca marche avec le char ?

Luzwitz a écrit:

et alors pourquoi quand je le compile sur mon ordinateur il n'y a pas d'erreur et quand je l’exécute ca marche avec le char ?

Parce que le compilateur de ton ordi n'est pas réglé avec le même niveau de détection de warning que celui du microcontrôleur.

PS: Attention, tu parles d'erreur ou de warning?

warning

Le premier code indique un warning. Ce warning indique que la boucle ne se terminera jamais. Et à l'exécution tu vois qu'il avait raison.
Alors pourquoi? Comme les char sont signés chez toi, la lecture sera tronquée à un char et donnera un nombre qui pourra aller de 0 à 255. Quand on atteint la fin du fichier, la fonction retourne la valeur EOF qui est tronquée en un nombre obligatoirement entre 0 et 255 et donc la comparaison c != EOF correspond à poser la question : est-ce qu'un nombre c allant de 0 à 255 peut il valoir -1(=la valeur de EOF)? Réponse du compilateur : "Ça n'arrivera jamais". On ne verra jamais la fin du fichier!

Le second code n'a pas le warning. A la place il a une autre erreur. on suppose maintenant les lectures tronquées dans un int8_t. Les valeurs possibles vont de -128 à +127. Le test qui suit est donc possible, mais il existe maintenant 2 cas où c peut valoir -1:
- quand la fonction getc() a retourné un EOF
- mais aussi (c'est là le bug) quand la fonction va lire le caractère '\xFF'. Ce caractère converti en int8_t devient -1. Il sera confondu avec une fin de fichier!

Il faut écrire un troisième code : Pouet_forever t'a indiqué quoi faire. Il n'y aura plus ni le warning du premier code, ni l'erreur du second code.

Luzwitz a écrit:

mais  ce n'est pas du au code, mais surement du au processeur, ...

Par defaut dit toi que l'erreur est TOUJOURS l'interface chaise clavier. Avant de dire un truc aussi gros que : c'est le processeur, pense au nombre de personnes dans le mondes utilisant un processeur comme le tien, si l'erruer venais de là elle serait connue depuis bien longetemps

-
Edité par ox223252 26 avril 2019 à 14:39:02