questions - Page 1

yop
quelques questions :

1.
quand on a :

    HANDLE handle;
    char *ptrFILE;
    SYM_ENTRY *sym;
    handle = HeapAlloc(16);
    if (!handle)   return;
    sym = DerefSym(SymAdd(SYM_STR("tuto")));
    if (!sym)  {HeapFree(handle);       return;}
    
    sym->handle = handle;
    ptrFILE = HeapDeref(handle);
    *(short*)ptrFILE = 14;
    ptrFILE[10] = 0;
    strcpy(ptrFILE+11,"TUT");
    ptrFILE[15]=OTH_TAG;

(tuto de Benji sur TI-Gen)
Une fois le fichier crée, on a bien 8 octets disponibles pour écrire quelque chose ?

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-----------+------+
|  0 |  1 |  2 | 3 |  4 |  5 |  6 | 7  | 8 |  9 | 10|11 |12| 13|14 |   15        |16    |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-----------+------+
| taille   |      données                           |  0 | T  | U |  T |  0 |OTH_TAG| 0(?) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-----------+------+
|     2    |               8                              |  1 |        3      |  1 |      1       |   1    |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-----------+------+

2. Je veux créer un fichier qui stockera les données des sprites que j'utilise :
le fichier est sous cette forme :

       taille : 2 octets
       nombre de données à lire par sprite (lignes) : 1 octet
       données : s octets
       autres : 0 // SPR // 0 // OTH_TAG // 0 (?) : 7 octets

soit :
+---+---+---+---+---+---+---+---+-----+------+------+----+------+------+-----+-----------+------+
|  0 |  1 |  2 | 3 |  4 |  ...            | s+1|  s+2 | s+3 |s+4 | s+5 | s+6 | s+7 | s+8        | s+9  |
+---+---+---+---+---+---+---+---+-----+------+------+---- +-----+------+------+-----------+------+
| taille   |     |            données                     |  0    | T     | U    |  T    |  0     |OTH_TAG| 0(?) |
+---+---+---+---+---+---+---+---+-----+------+------+---+---+---+-----+------+-----------+------+
|     2    | 1  |                    s                         |  1     |        3      |  1    |   1   |       1     |     1   |
+---+---+---+---+---+---+---+---+-----+------+------+---+---+---+---+--------+------+---+-------+

La taille du fichier est donc bien de s+9 octets ?
J'ai essayé ce code

SYM_ENTRY *sym = SymFindPtr(SYM_STR("spr",0);

if (!sym)
{
    HANDLE handle;
    char *ptrFILE;
    handle = HeapAlloc(s+9);
    if (!handle)   return;
    sym = DerefSym(SymAdd(SYM_STR("spr")));
    if (!sym)  {HeapFree(handle);       return;}
    
    sym->handle = handle;
    ptrFILE = HeapDeref(handle);
    *(short*)ptrFILE = s+7;
    ptrFILE[s+3] = 0;
    strcpy(ptrFILE+s+4,"TUT");
    ptrFILE[s+8]=OTH_TAG;
}

... //écriture des données ici, c'est un tableau de [i]char[/i]

mais ça me donne des résultats bizarres dans le Var-Link...




3.Comment créer un tableau de char à dimension s, s étant une variable de type short ?
comme ça :

char *spr = (char*) malloc(s*sizeof(char));

?

et une fois le tableau crée, comment pouvoir récupérer les données avec memcpy() ?
parce que

... //suite du code précédent
memcpy(spr, ptrFILE + 4, ptrFILE + 3);

ne me donne pas les bonnes données ; sinon, y a toujours moyen de le faire avec une boucle for, "à la main", mais j'préfère éviter


voilà voilà, merci pour les éventuelles réponses ^^



(désolé pour le décalage pour les tableaux ....)

tama (./1) :
Une fois le fichier crée, on a bien 8 octets disponibles pour écrire quelque chose ?

Oui.

La taille du fichier est donc bien de s+9 octets ?

Oui.

mais ça me donne des résultats bizarres dans le Var-Link...

Je ne comprends pas trop, parce qu'à première vue d'œil, je ne vois pas d'erreur dans ce code.

3.Comment créer un tableau de char à dimension s, s étant une variable de type short ?
comme ça :

char *spr = (char*) malloc(s*sizeof(char));

?

Oui, mais comme sizeof(char)==1, le *sizeof(char) est redondant.

et une fois le tableau crée, comment pouvoir récupérer les données avec memcpy() ?
parce que

... //suite du code précédent
memcpy(spr, ptrFILE + 4, ptrFILE + 3);

ne me donne pas les bonnes données

C'est normal, tu essaies de passer un pointeur en troisième argument à la place de la longueur qu'il faut. (Tu devrais d'ailleurs avoir reçu un avertissement du compilateur pour ça!)

effectivement, je n'avais pas remarqué ça...
il faut donc remplacer "ptrFILE + 3" par ptrFILE[3] ?

EDIT : pour le 2ème code, erreur de frappe, c'est bon c'est résolu

Non [EDIT: enfin si, j'ai écrit ça avant de lire ton edit], par un entier. Peut-être ptrFILE[3] est ce que tu cherches, mais attention, tu ne lis qu'un char là, il te faut plutôt ((unsigned short*)ptrFILE)[1] (qui peut aussi s'écrire 1[(unsigned short*)ptrFILE] à cause de la manière dont est définie l'arithmétique de pointeurs et de tableaux en C et qui correspond à *(unsigned short*)(ptrFILE+2) (tu préfèreras peut-être cette écriture)).

hmm j'avais écrit

ptrFILE[3]

mais j'avais oublié les balises, donc il l'a pas capté, d'où la couleur verte
ok ok, j'ai compris, j'vais utiliser la dernière écriture : *(unsigned short*)(ptrFILE+2)

Kevin Kofler (./2) :
Oui, mais comme sizeof(char)==1, le *sizeof(char) est redondant.

Pas partout (demande à Ximoon ), donc vu que ça ne coute rien autant le mettre et conserver un code un peu plus portable.

Zephyr (./6) :

Pas partout (demande à Ximoon ), donc vu que ça ne coute rien autant le mettre et conserver un code un peu plus portable.

Si, si partout.
sizeof (char) == 1 (Cf la norme). C'est même l'unité de sizeof.
Ensuite, 1 'sizeof' peut être équivalent à 4 octets derrière.

Le fameux c4x.

Toujours est-il que ça ne coûte rien de laisser le sizeof, je sais que tu n'es pas partisan de la lisibilité du code Kevin, mais franchement, autant le laisser

(Et j'étais effectivement tombé sur un C5x pour lequel sizeof(char) == sizeof(short) == 1, le char étant sur 16 bits)

Pour moi, le code illisible, c'est le code bourré d'opérations redondantes qui reviennent à faire du *1, du +0 ou du !=false.

Le but du code lisible, c'est justement que d'autres que toi puissent le lire, donc ton avis...

hmm...petit problème : j'ai bien le fichier comme il faut, mais dans le Var-Link ça apparait sous l'extension "EXPR" avec la taille 2...

voilà la source (c'est programmé avec GTC oncalc) #include <tigcclib.h> void _main() {         SYM_ENTRY *sym;         sym = SymFindPtr(SYMSTR("font"),0);         HANDLE handle;         char *ptrFILE;                  static char data[]=         {                5,    //nombre de lignes                                 0b01110000,     //0                 0b10001000,                 0b10001000,                 0b10001000,                 0b01110000,                 0b00100000,     //1                 0b01100000,                 0b10100000,                 0b00100000,                 0b11111000,                 0b11110000,      //2                 0b00001000,                 0b01110000,                 0b10000000,                 0b11111000,                 0b11110000,      //3                 0b00001000,                 0b01110000,                 0b00001000,                 0b11110000,                 0b10000000,       //4                 0b10010000,                 0b10010000,                 0b11111000,                 0b00010000,                 0b11111000,       //5                 0b10000000,                 0b11110000,                 0b00001000,                 0b11110000,                 0b01111000,        //6                 0b10000000,                 0b11110000,                 0b10001000,                 0b01110000,                  0b11111000,        //7                 0b00001000,                 0b00010000,                 0b00100000,                 0b00100000,                 0b01110000,         //8                 0b10001000,                 0b01110000,                 0b10001000,                 0b01110000,                 0b01110000,                 0b10001000,                 0b01111000,                 0b00001000,                 0b11110000,         };    short size = sizeof(data)/sizeof(char); //oui, je sais que ça fait 1     handle = HeapAlloc(size+9);            if (!handle)    return; if (!sym) {  //création du fichier           sym = DerefSym(SymAdd(SYMSTR("font")));    if (!sym)    {HeapFree(handle);  return;}  //inutile ?         sym->handle = handle;         ptrFILE = HeapDeref(handle);         *(short*)ptrFILE = size+7 //l'erreur serait ici ?         ptrFILE[size+3] = 0;         strcpy(ptrFILE+size+4,"FNT");         ptrFILE[size+8] = OTH_TAG; //copie des données          memcpy(ptrFILE+2,data,size); } else {          sym->handle = handle;          ptrFILE = HeapDeref(handle); } short s=ptrFILE[3]; short chs = 0; char *spr = (char *)malloc(s*sizeof(char)); memcpy(spr,data+s*chs+1,s); Sprite8(80,80,s,spr,LCD_MEM,1); HeapFree(handle); }        

je précise qu'au lancement du programme, le fichier "FONT" n'est pas présent...

EDIT : oublié un ";" à la ligne "*(short *) ptrFILE = size + 7" dans la source.
elle y est bien dans le programme que j'ai fait

Bon, la bonne nouvelle, c'est que ton code compile sans modifications avec TIGCC.

La mauvaise nouvelle, c'est que je vois au moins 2 bogues dans ton code:
1. Le pointeur sym retourné par SymFindPtr n'est plus valide après un HeapAlloc. Ton if (!sym) passera toujours (un pointeur nul reste un pointeur nul), mais dans ton cas else, ton sym->handle = handle; ne passe pas. D'ailleurs, je ne vois pas pourquoi tu alloues un nouveau handle quand le fichier existe déjà au lieu de réallouer celui qui existe déjà avec HeapRealloc.
2. Tu libères ton handle avec HeapFree à la fin. Tu n'as pas le droit de faire ça ici! Le handle appartient au fichier que tu viens de créer, il ne faut pas t'étonner que tu corromps ton fichier si tu lui supprimes son handle!

Ben il compile aussi avec GTC. Et ce que tu dis est effectivement une bonne nouvelle, je suis d'accord : ça montre que TIGCC et GTC sont compatibles (j'ai constaté la même chose en compilant plusieurs sources, dont TiCon45, TIChess, Einstein et d'autres codes).

Ben voyons, pas un pour rattraper l'autre... Si c'était pas qu'ils en aient déjà par-dessus la tête de ce troll récurrent, je ferais bien un appel des modos habituels...

Puisque tu n'es pas capable (pas plus que Kevin) de présenter les choses correctement - à savoir que tu as testé avec une vieille version - je te demande d'arrêter purement et simplement d'utiliser TI-Chess comme exemple de compatibilité de GTC avec TIGCC.

Les incompatibilités de la dernière version ne sont pas dues au code C je crois. Donc je continuerai à le citer parmi d'autres programmes C compatibles

Tu essaies de programmer quoi tama ?

Tu pourrais faire preuve d'intelligence, de temps en temps ?
Ca peut déclencher quoi, à ton avis, ta réaction de persister dans ton tort ? Que quelqu'un ait une réaction aussi stupide que la tienne et participe à creuser plus profond tous ensemble dans le bac à sable, en corrigeant ta désinformation à chaque fois qu'elle est postée ?

Peut-être le problème vient-il de toi. Si on parle de compatibilité du code C, le test de TiCon45 dans sa version C-only est parfaitement valable.

la "discussion" GTC vs TIGCC, en gros tout le monde la connaît, et à peu près tout le monde en a assez, je crois... Vous voudriez pas régler ça entre vous, genre par mini-messages ?
(ou même ne pas le régler, vu que vous serez jamais d'accord, parti comme c'est... mais si c'est entre vous, le résultat compte peu, tant que ça arrête d'en repasser 36 couches dans 36 topics...)

merci

alors

Bon, la bonne nouvelle, c'est que ton code compile sans modifications avec TIGCC.

oui, j'ai aussi remarqué ça

La mauvaise nouvelle, c'est que je vois au moins 2 bogues dans ton code:
1. Le pointeur sym retourné par SymFindPtr n'est plus valide après un HeapAlloc. Ton if (!sym) passera toujours (un pointeur nul reste un pointeur nul), mais dans ton cas else, ton sym->handle = handle; ne passe pas. D'ailleurs, je ne vois pas pourquoi tu alloues un nouveau handle quand le fichier existe déjà au lieu de réallouer celui qui existe déjà avec HeapRealloc.

Oui, je m'en suis aussi rendu compte, j'ai supprimé ces lignes, ça marche maintenant
(précaution par rapport à l'ASM z80 qui crée un fichier même si un fichier de même nom existe déjà, qui est inutile ici)

2. Tu libères ton handle avec HeapFree à la fin. Tu n'as pas le droit de faire ça ici! Le handle appartient au fichier que tu viens de créer, il ne faut pas t'étonner que tu corromps ton fichier si tu lui supprimes son handle!

Pareil, je l'ai enlevé et ça marche maintenant
mais j'me pose une question : le fait de ne pas libérer le Handle ne provoque t-il pas de perte de mémoire ?

Thibaut>je reprends un jeu que j'avais commencé à programmer il y a longtemps de cela ^^

sinon, simple curiosité :

#include <tigcclib.h>

void _main()
{
        long o = 100000;
        long p = 1;
        long result = o * p;
        printf("%ld",result);
}

pourquoi ça affiche 34464 (sachant que 100000 - 34464 = 65536) ?
pourtant 100000 rentre bien dans un long ?
et si je remplace o par 1000 et p par 100 ça marche (i.e ça affiche 100000)

tama (./21) :
mais j'me pose une question : le fait de ne pas libérer le Handle ne provoque t-il pas de perte de mémoire ?

La mémoire n'est pas perdue parce qu'elle appartient au fichier.

tama (./21) :
pourquoi ça affiche 34464 (sachant que 100000 - 34464 = 65536) ?

Parce que ton compilateur est bogué, TIGCC donne le bon résultat.

Ce que tu peux essayer, c'est écrire 100000L au lieu de 100000, mais d'après le standard C, ça ne devrait pas être nécessaire (une constante qui ne rentre pas dans un int est automatiquement un long).

Kevin Kofler (./22) :

tama (./21) :
mais j'me pose une question : le fait de ne pas libérer le Handle ne provoque t-il pas de perte de mémoire ?

La mémoire n'est pas perdue parce qu'elle appartient au fichier.

ok

tama (./21) :
pourquoi ça affiche 34464 (sachant que 100000 - 34464 = 65536) ?

Parce que ton compilateur est bogué, TIGCC donne le bon résultat.

=/
bon, pas grave j'ai trouvé un autre moyen de toute façon

Oula oui c'est un énorme bug... C'est corrigé, en attendant tu peux faire o*(short)p au lieu de o*p et ça devrait renvoyer 100000 ^^

Ah, c'est pas à l'assignation qu'il y avait l'erreur ? Ben merci pour ta rapidité Tu penses ajouter les licences un jour et publier GTC ou tu laisses tomber ?

Je les ajouterai un jour, par contre je sais pas si je m'embêterai à trouver un workaround pour les flashapps que TI ne veut apparemment plus signer...

Est-ce que GTC utilise beaucoup les features des FlashApps pour se hooker à divers endroits du système ou redéfinir des trucs ?
(Le portage direct sur PedroM nécessiterait d'avoir le système d'événements complet dans PedroM, donc c'est pas pour tout de suite...)

Pollux répondra mieux que moi, mais là j'ai rien à faire alors je vais essayer de réfléchir un peu :

Je pense que les hooks ne sont pas utiles pour un compilateur, et je ne pense pas qu'il soit nécessaire de redéfinir des valeurs ou autre. Un compilateur fait uniquement du traitement de données, et de façon autonome. Il n'a pas besoin du système si ce n'est pour lire la source et écrire le résultat.

Et puis de telles utilisations de l'OS compliqueraient le portage DOS-TIOS.