Vertyos
a écrit :
De plus le problème c'est pas qu'elles COMPTENT 2 octets de moins que la taille du fichier, c'est que la lecture et l'écriture commence à l'octet n°2, pour éviter de modifier les octets de taille qui n'ont pas à être changés (sauf cas exceptionnel que stdio.h ne peut de toute façon pas gérer).
Et ben, c'est parce que ces octets ne font pas partie du fichier.
Donc :
Taille d'un fichier == Mémoire totale occupé sur le support qui le contient 
Non. Si tu prends un fichier texte sur PC, et que tu écris "Hello, World!" dedans, le PC t'affichera une taille de 13 octets, pas de 4 KO (en admettant une taille de cluster de 4 KO - c'est le minimum pour une partition FAT32), même si la mémoire totale occupée sur le support qui le contient est de la taille d'un cluster.
Que tu ne l'entende pas de cette façon là, c'est un tout autre problème...
Ce n'est pas que je ne l'entends pas de cette façon-là, c'est que ce n'est pas comme ça!
Au fait, si les octets de taille faisaient 100 octets tu ne les compterais quand même pas ?
Non.
Dans mon exemple sur PC, les octets supplémentaires sont 4083 octets, mais ils ne sont quand-même pas comptés.
D'ailleurs, si tu veux absolument compter la taille de la mémoire effectivement consommée par un fichier sur TI-89/92+/V200, il faudra rajouter:
- les 16 octets de gestion interne des blocs
- les 14 octets consommés par la structure
Vertyos a écrit :
Ouais bon... Quand j'ai dit 65535 c'était pour expliquer à Link que 2 octets suffisaient, ça fait un moment que je me suis rendu compte qu'on pouvait pas dépasser 65520
On ne peut pas dépasser un offset de 65517 (65518-1), parce que les offsets ne pointeront jamais dans les 2 octets de taille.
