As et HeapAlloc - Page 1

Je n'arrive pas a allouer de la memoire avec cc de nitro sans que ca plante!
Tenez,par exemple:

unsigned short HeapAlloc();
char *HeapDeref();
void HeapFree();
short DlgMessage,

void main(){
short *tab;
unsigned short handle;
handle=HeapAlloc(50*sizeof(short));
tab=(short *)HeapDeref(handle);
if(!tab){
DlgMessage("ERREUR","Allocation echouee!",0,1);
}
else{
DlgMessage("SUCCES",Allocation reussie!",0,1);
HeapFree(handle);
}
}

me fait planter la calculette,meme si l'allocation a reussie!

Fais voir la source ASM générée.
Ça plante à quel moment ?

Dans la doc de TIGCC
il est écrit : Note: HeapDeref returns a garbage if Handle is H_NULL.

Je ne sais pas ce que veut dire 'a garbage'. Je crois que ça veut simplement dire que la fonction retourne n'importe quoi, donc ce n'est peut-être pas la peine de rajouter un test pour vérifier la validité du HepAlloc. De toute façon ton plantage ne vient proobablement pas de là, puisque même quand l'allocation réussit ça plante.

Sinon, peut-être que les fonctions DlgMessage peuvent entrainer une Heap Compression. Tu devrais essayer de vérouiller ton handle pour voir si ça ne vient pas de là.

Si tu veux,pour chaque HANDLE,il y a une addresse instable,d'ou l'emploi de handle,numero qui pointe toujours vers la meme zone memoire allouee(Ca,c'est ce que j'ai pu lire dans des docs).Et le garbage collection change toutes les addressses mais pas les handles

Maintenant,en ce qui concerne le verrou des handles,je vais essayer.Mais je pensais pas qu'une fonction comme DlgMessage puisse entrainer un garbage collection
(Honte a moi,et de regarder la doc avant d'utiliser les handles!)

je te passe le asmsrc produit:  include "ams_c"  bra _main L4:  dc.b 65,108,108,111,99,97,116,105,111,110,32,114  dc.b 101,117,115,115,105,101,0 L3:  dc.b 83,85,67,67,69,83,0 L2:  dc.b 65,108,108,111,99,97,116,105,111,110,32,101  dc.b 99,104,111,117,101,101,33,0 L1:  dc.b 69,82,82,69,85,82,0  even _main:  link a6,#-6  move.l d3,-(a7)  move.w #100,-(a7)  jsr _HeapAlloc  addq.l #2,a7  move.w d0,d3  move.w d3,-(a7)  jsr _HeapDeref  addq.l #2,a7  move.l a0,-4(a6)  bne L5  move.w #1,-(a7)  move.w #0,-(a7)  pea L2  pea L1  jsr _DlgMessage  lea 12(a7),a7  bra L6 L5:  move.w #1,-(a7)  move.w #0,-(a7)  pea L4  pea L3  jsr _DlgMessage  lea 12(a7),a7  move.w d3,-(a7)  jsr _HeapFree  addq.l #2,a7 L6:  move.l -10(a6),d3  unlk a6  rts

En utilisant HeapLock et HeapUnlock,j'ai rendu le programme pire qu'avant:

handle=HeapAlloc(50*sizeof(short));
HeapLock(handle);
...
DlgMessage("ECHEC"...);
HeapUnlock(handle);//Si j'enleve cette ligne ca n'arrange rien
...
Dlgmessage("SUCCES",...);
HeapUnlock(handle); ...

Ça plante à quel moment précisément ?
au fait, j'ai regardé dans la doc de tigcc à la fonction DlgMessage :

This routine may cause heap compression

Pour le premier programme,c'est une fois que la boite de dialogue "SUCCES" disparait
pour le deuxieme,c'est des que je lance le programme

Pfff, j'ai enfin trouvé le bug...
Regarde le protoype de HeapAlloc. Il lui faut un long en paramètre et tu passes un short.
La bonne ligne de code est : handle=HeapAlloc((long)(50*sizeof(short)));

ok merci!
la prochaine fois j'y ferais attention.(c'est la que ca sert de programmer proprement deja sur tigcc!)

jackiechan
a écrit : Je ne sais pas ce que veut dire 'a garbage'. Je crois que ça veut simplement dire que la fonction retourne n'importe quoi, donc ce n'est peut-être pas la peine de rajouter un test pour vérifier la validité du HepAlloc.

Si, justement, il faut tester la validité du HeapAlloc et pas du HeapDeref comme il l'a fait.


Et pour l'erreur, en effet, CC a passé un short. C'est un bogue de CC: il considère sizeof(short) comme un short, ce qui est faux: sizeof est censé renvoyer un size_t, et size_t est unsigned long sous AMS.

Et sinon, un garbage collection c'est pareil qu'une heap compression ou pas du tout ?

Une "garbage collection" de la RAM oui. Mais ce n'est pas le terme utilisé par TI, et il prête à confusion (avec la réorganisation des archives), donc il vaut mieux l'éviter et de parler de "heap compression".