un probleme avec des handle - Page 1

je pige pas un truc avec ces satané handle : avec la fonction ci-apré , desfois ca bug et desfois ca bug pas , pourtant ca parait correct .... je comprend vraiment pas

#define stop(a){clrscr();printf(a);ngetchx();}
void* cree_un_nouveau_fichier(char* nom,short taille)
{
  void* vptr;
  HANDLE h=HeapAlloc(taille+2);
  HSym hsym = SymAdd (SYMSTR(nom));  
  SYM_ENTRY *ptr = (DerefSym (hsym)); 
  stop("avant la def du handle");
  ptr->handle=h;// c'est ici que ca bug! 
  stop("apré");
  vptr=HeapDeref(ptr->handle);
  *(unsigned short *)vptr =(unsigned short)taille;
  return  (vptr+2);
}

qqun peut m'expliquer le probleme, merci beaucoup

sinon g aussi essayé ca mais sans succes

void* vptr;
  HSym hsym = SymAdd (SYMSTR(nom));  
  SYM_ENTRY *ptr = (DerefSym (hsym)); 
  ptr->handle=HeapAlloc(taille+2); // ca non plus ca marche pas
  vptr=HeapDeref(ptr->handle);
  *(unsigned short *)vptr =(unsigned short)taille;
  return  (vptr+2); 

et juste au cas où, je situe où je l'utilise cette fonction ki marche pas:
je l'utilise en faisant ceci: je tire d'une matrice principale qq données que je mets ds une matrice secondaire en utilisant un fopen puis je cree ma seconde matrice avec cette fnc puis je fé un fread de la 1ere vers la 2nd matrice (fread(vptr,,,f))

a oui g oublié de preciser quelle erreur il se produit ...
sur la ti, j'ai : " protected memory violation "

j'ai beau reflechir je ne pige pas pkoi ,
a moins qu'il y ait un heapcompress juste avant le heapderef mais ca parait impossible

pourquoi te prend tu la tete avec des handle ???
utilise fopen et companie ce sera plus simple!

fopen c'est lent et ça prend plein de place, je vois pas en quoi c'est une meilleure solution...

Heu sinon pour créer des fichiers j'utilise ça, ça n'a jamais planté mais peut-être que j'ai eu de la chance ?

SYM_ENTRY *TiOSMake(const unsigned char *name,unsigned short size)
{
	SYM_ENTRY *sym = NULL;

	if (size < 2 || size > 65520)
	{
		Error("\016 2 \x9C var size \x9C 65520");
		return NULL;
	}

	if (!(sym = DerefSym(SymAdd(SYMSTR(name))))
	 || !(sym->handle = HeapAlloc(size)))
	{
		if (sym) SymDel(SYMSTR(name));

		Error("\016 Unable to create variable");
		return NULL;
	}

	*(unsigned short*)HeapDeref(sym->handle) = size - 2;

	return sym;
}

[edit] Hum... Y'a un truc spécifique au prog là dedans, deux minutes je le retire
[edit] Ça a l'air correct... Enfin j'espere, pas le temps de vérifier :/

Faudrait que tu donnes aussi le code de TiOSOpen

Heu non, erreur de ma part, cf edit y'en a pas besoin ^^
Le TiOSOpen c'était pour que la fonction réalloue le fichier au cas ou il existait déjà.

Ton code a une chance non nulle (même si faible) de planter : après un HeapAlloc, tu n'as aucune garantie que ton pointeur vers le SYM_ENTRY est tjs valide (la table du contenu du répertoire peut avoir bougé) Tu peux verrouiller les tables des répertoires avec FolderOp, ou tu peux refaire un DerefSym...

(enfin dans ce cas précis il y a bien plus simple :

	HANDLE hd = HeapAlloc(size);
	if (!hd || !(sym = DerefSym(SymAdd(SYMSTR(name)))))
	...

et ça permet même d'éviter la ligne qui suit : plus besoin de faire de SymDel)

Conclusion: Vertel est boguée. Et comme tu ne distribues pas la source, on n'aurait eu aucun moyen de le savoir avant que ce soit trop tard si tu n'avais pas posté cet extrait ici.

Je ne pense pas que ce bug arrive souvent, et de toute façon même s'il avait distribué officiellement la source, je ne pense pas que bcp de monde l'aurait lue en entier pour chercher les bugs

Kevin Kofler
: Conclusion: Vertel est boguée. Et comme tu ne distribues pas la source, on n'aurait eu aucun moyen de le savoir avant que ce soit trop tard si tu n'avais pas posté cet extrait ici.

Raté, ce n'est pas le code de Vertel

Pollux > Ok, merci, je reverrais ça (plus tard, là je vais pas tarder à partir pour l'open ^^)

ca marche pas non plus, ..... je comprend vraiment pas c surement le contexte d'utilisation qui va pas ...

et pollux, ce ne serait pas ce que j'ai fait en premier ?? .....

avant de creer la variable , j'ai ouvert un fichier avec fopen, je me demande si je dois pas le fermer pour creer un nouveau fichier...

C'est vraiment bizzare que ça ne marche pas *du tout*... Même si d'après Pollux le code a une faible chance de bugger, ça devrait quand même fonctionner dans une très très large majorité des cas, ton erreur doit venir d'ailleurs.

kevin, tu pourrais pas m'aider ???

non j'ai testé , retesté et rere.... avec des marqueurs pour voir où ca sa plante , et sa plante toujours au meme endroit pour ma fonction quant a la tienne elle me renvoit Error("\016 Unable to create variable"); ,
c la definition du handle qui plante ds tou les cas mais pkoi????????

matthieu
: et pollux, ce ne serait pas ce que j'ai fait en premier ?? .....

j'avais pas regardé ton code, mais en tout cas tu ferais mieux de mettre tous les tests (savoir si l'allocation a réussi ou pas, si le HSym est nul ou pas...) Parce que ça peut très bien se situer ailleurs, genre nom="f@``d\_é", et résultat on ne peut pas créer le fichier...

Commence par vérifier que ton SymAdd n'a pas échoué (c'est-à-dire renvoyé HS_NULL). Sinon, c'est râté d'avance.

kevin tu a raison
le ptr sym_entry est null
...

Peut-être que tu donnes un nom réservé à ton fichier? Ou alors un nom trop long?

ca y'est g reglé le probleme
je ne sais absolument pas comment j'ai fait mais j'ai reussi , je crois que pollux avait raison packe j'ai juste rajouté nom=NULL

merci a tous !!!!!