fopen - Page 2

Chais pas.

FILE *fopen(const char *name asm("a0"), const char*mode asm("a1"));

Peut être le fait que l'argument de nom va dans a0 et le mode dans a1 ?

Folco_ (./34) :
(puis le beau trick de Pollux tombe allo )

En fait, ça marche encore :

	swap	a0,sp
	bsr.s	\Mode
	dc.b	"r",0
Mode:	swap	a0,sp

pardon, c'était la plaisanterie asm du dimanche soir

Sauf que ca prend 2 octets de plus qu'un simple lea \Mode(pc),a0

je sais, je sais, c'était juste pour la beauté du trick

J'ai un souci encore avec fopen ...

Je passe l'adresse du nom du fichier à ouvrir dans a0, et l'adresse de "r",0 dans a1
Je me retrouve avec dans a0 $5e2a. Je vais voir à $5e2a, j'y vois $00010005. Comme ça ressemble à un hsym, je vais voir le handle 5 situé à $8f9e, j'y trouve 4 octets de header de fichier texte, puis le contenu du texte que je cherche.

Que pasa ? J'aurais pensé tomber directement sur un pointeur vers mon texte, non ? Ou alors je déconne sec, comme souvent ...
(note : j'ai la dernière alpha de PedroM)

Oublié de préciser une chose : dans mon exemple, si je vais voir à $10005 (ce que je pense être un hsym), il n'y a que des \0 à perte de vue

Je vois pas le problème.
Pourquoi tu n'utilises pas les fonctions f* ?

Pourquoi d'autres fonctions f* ? Je pensais que fopen allait me renvoyer un pointeur sur le début du texte, c'est pas le cas ? Il est censé renvoyé un FILE *, non ? C'est pas le début du flux ?

PpHd (./36) :
Sauf que ca prend 2 octets de plus qu'un simple lea \Mode(pc),a0

et surtout ça marche pas parce que a0 ne pointerait qu'indirectement vers "r" ^^ par contre sans swap et avec un move.l (a7)+,a0 ça marche et ça prend pas plus de place qu'un lea enfin ça a quand même un inconvénient, ça prend plus de place dans la fonction elle-même donc ça pourrait transformer des bxx.s en bxx.w -- mais on peut aussi considérer le bsr comme un avantage de ce point de vue-là, puisque le saut introduit permet de réorganiser le code de la fonction et de rapprocher du code qui aurait nécessité des bxx.w

Bon ok, merci à Kevin pour ses explications sur IRC, je vais m'y prendre autrement, je ne pensais pas que fopen agissait comme ça. Désolé.

J'avais en fait pas compris qu'un FILE * est un "truc" qu'on repasse après à l'OS pour utiliser d'autres fonctions derrière, donc qu'en quelque sorte, on se fout pas mal de ce que c'est. J'étais content, croyant avoir trouvé une fonction qui m'évitais de faire un SYMSTR/SymFindPtr/get_handle/HeapGetLock/HeapLock/HeapDeref ^^

haha

Oué bon ça va hein

Pour la peine je vais écrire oopenlib.org (Open open lib ) pour renvoyer un pointeur sur le premier octet de données des fichiers

J'espère que ce sera open source

Ben normalement oué

c'est bien, tu es open mind

</dehors>

Bon, question sûrement évidente pour vous, unixiens et C-istes de tout poil :
Si je fais un ftell( fopen( *myfile, *R ))), je vais bien avoir mon pointeur de début de fichier, non ?
Le handle sera bien locké par fopen et éventuellement délocké par fclose (suivant son état initial) ?

euh non ça va te dire l'offset par / au début du fichier, donc zéro

Donc je suis condamné à utiliser f* pour lire si j'utilise fopen ? Ca m'aurait plu de pas utiliser toute la manip SYMSTR/SymFindPtr/get_handle/HToESI/HeapGetLock/HeapLock/HeapDeref pour avoir ce p*tain de pointeur. Mais bon, c'est déjà codé. Mais ya pas moyen de faire plus court avec fopen alors ?

Juste pour te rassurer, fopen ne fait même pas de lock du handle

Nan c'est pas vrai !?! Mais c'est casse-gueule ton truc Bon ben je reste avec mon code déjà prêt. Je crois que fopen fait quand même une vérification du type de fichier dans certains cas ?

Folco (./51) :
Donc je suis condamné à utiliser f* pour lire si j'utilise fopen ? Ca m'aurait plu de pas utiliser toute la manip SYMSTR/SymFindPtr/get_handle/HToESI/HeapGetLock/HeapLock/HeapDeref pour avoir ce p*tain de pointeur. Mais bon, c'est déjà codé. Mais ya pas moyen de faire plus court avec fopen alors ?

Tigcclib ne s'embête pas avec HeapGetLock apparemment (donc vaut mieux pas ouvrir deux fois le même fichier ), seulement HLock/HeapUnlock.

Et HeapGetLock ne résoud le problème que si tu fermes tes fichiers dans l'ordre inverse de l'ouverture, ce que n'impose pas fopen/fclose...

!call Kevin Kofler
--- Call : Kevin Kofler appelé(e) sur ce topic ... (pour savoir si c'est voulu, et pour au moins le mentionner dans la doc)

L'absence de HeapGetLock me semble assez dangereuse, le fichier peut avoir été locké par autre chose et devrait donc normalement être retourné dans le même état, je devrais peut-être le corriger, même si d'un autre côté ça n'a pas l'air d'avoir posé problème.

Mais ouvrir le même fichier plusieurs fois dans le même programme n'est pas du tout prévu, et franchement je ne vois pas trop l'intérêt.

Donc je suis condamné à utiliser f* pour lire si j'utilise fopen ?

Oui, à moins d'utiliser le contenu de la structure FILE (ce qui est TRES sale, non portable et non évolutif ).
Mais bien sûr, l'utilisation de f* entraîne un overhead vitesse (et assez souvent également un overhead taille si on fait des programmes non natifs PedroM, parce qu'il faut mettre le code des f* dans le programme) par rapport à la lecture/écriture directe à base de pointeurs / memcpy / memset.

Kevin Kofler (./55) :
L'absence de HeapGetLock me semble assez dangereuse, le fichier peut avoir été locké par autre chose et devrait donc normalement être retourné dans le même état, je devrais peut-être le corriger, même si d'un autre côté ça n'a pas l'air d'avoir posé problème.

Mais ouvrir le même fichier plusieurs fois dans le même programme n'est pas du tout prévu, et franchement je ne vois pas trop l'intérêt.

Ben au hasard prends un compilo qui doit gérer des includes récursifs... (en général les fichiers sont archivés donc le problème a peu de chances d'être remarqué, mais il est bien là)

Je crois pas que ce serait une bonne solution de se contenter de

fopen:
 f->locked = HeapGetLock(f->handle);

fclose:
 if (!f->locked)
   HeapUnlock(f->handle);

parce qu'on veut pas que ce programme

f1 = fopen();
f2 = fopen();
fclose(f1);
fread(f2);
fclose(f2);

foire silencieusement.

Je vois ces solutions-là :
- que les fopen() créent un compteur de références partagé et que seul le dernier fclose() délocke le fichier : le seul moyen de simuler un vrai fopen(), mais c'est compliqué et ça prend de la place
- arrêter l'exécution ligne 2 en refusant d'ouvrir un handle locké non-archivé : c'est le plus simple, mais peut-être que ça gêne certains programmes et ça empêche d'ouvrir deux fois le même fichier (donc inutilisable pour un compilateur, par exemple)
- arrêter l'exécution ligne 3 : impossible sans une vraie communication entre les instances de fopen()
- arrêter l'exécution ligne 4 en appelant HeapGetLock() à chaque accès au fichier, mais ça ralentit (autant ne pas locker le fichier et utiliser HeapDeref, à ce moment-là...)
- arrêter l'exécution ligne 5 en appelant HeapGetLock() avant de fermer le fichier, mais il faut un moyen propre de signaler l'erreur et/ou de faire planter le programme

Moi je penche plutôt pour la dernière solution ^^

Moi je dit un crash en bon et due forme, franchement ya pas mieux (scramble du screen, vidage aléatoire de la mémoire & co, une fois bien codé ça peut etre sympa, et a vrai dire le gars qui a fait une bétise, je peut te dire qu'il ne recommencera pas de sitôt ^^

Perso j'ai résoudru ce problème avec une table des fichiers ouverts. Si on essaye de réouvrir un fichier, le pointeur sur le premier octet () du fichier déjà ouvert est renvoyé. Sinon, ça ouvre le fichier en le lockant éventuellement, et en rajoutant dans la table (sur le bit #31 du pointeur vers le nom du fichier ) s'il faut le délocker en sortie ou pas. PedroM étant multithread, c'est une évidence de prévoir ça.

(sur le bit #31 du pointeur vers le nom du fichier )

Oh, bonne idée, ça !
Sur 68000 et 68010, qui ne gèrent que les 24 LSB des 32 bits du PC, tu peux effectivement utiliser le pointeur avec le bit 31 set tel quel (sans masquer le bit 31).

Ca fait une autre utilisation créative de l'étendue limitée des pointeurs sur 68000