Je n’avais pas tilté que le fichier était virtuel...
Sinon j'aurai utilisé le classique combo fseek/ftell/fseek :)
La fonction read renvoie le nombre d’octets réellement lus. En définissant un grand buffer ça devrait marcher. En plus, comme Linux n’alloue les pages que quand elles sont utilisées, on peut allouer 1M sans avoir peur.
Ça, ça dépend de la configuration du kernel si je ne dis pas de conneries (/proc/sys/overcommit_memory).
Personnellement, je trouve que c'est plus une gêne qu'une fonctionnalité: l'overcommit fait qu'on ne peut pas faire confiance au système quant au fait que les ressources qu'il nous à confiées sont réellement utilisables.
Je ne vais pas m'étendre la-dessus, mais je préfère éviter de me fier à ce type de mécanisme, et ce, particulièrement pour les applications que je fais pour ma pomme (si le chef me demande de faire le goret après tout, ainsi soit-il, hein, mais j'essaierai quand même d'éviter).
Enfin, certes, 1M, ce n'est pas grand chose, et c'est vrai que ta méthode marche, surtout qu'il suffit de faire d'abord une allocation de bourrin pour récupérer la véritable taille puis ajuster. Je n'y avais pas pensé je le reconnais.
M'enfin, dommage tout de même de ne pas avoir un mécanisme plus efficace (alloc, read, free, alloc, free, 5 appels système, pour quelque chose qui devrait pouvoir se faire plus facilement je pense, et si on doit faire ça de façon répétitive pour les 35K fichiers la fragmentation mémoire risque d'être conséquente à force).
[^] # Re: man fstat
Posté par freem . En réponse au message taille du "fichier" /proc/meminfo. Évalué à 3.
Sinon j'aurai utilisé le classique combo fseek/ftell/fseek :)
Ça, ça dépend de la configuration du kernel si je ne dis pas de conneries (/proc/sys/overcommit_memory).
Personnellement, je trouve que c'est plus une gêne qu'une fonctionnalité: l'overcommit fait qu'on ne peut pas faire confiance au système quant au fait que les ressources qu'il nous à confiées sont réellement utilisables.
Je ne vais pas m'étendre la-dessus, mais je préfère éviter de me fier à ce type de mécanisme, et ce, particulièrement pour les applications que je fais pour ma pomme (si le chef me demande de faire le goret après tout, ainsi soit-il, hein, mais j'essaierai quand même d'éviter).
Enfin, certes, 1M, ce n'est pas grand chose, et c'est vrai que ta méthode marche, surtout qu'il suffit de faire d'abord une allocation de bourrin pour récupérer la véritable taille puis ajuster. Je n'y avais pas pensé je le reconnais.
M'enfin, dommage tout de même de ne pas avoir un mécanisme plus efficace (alloc, read, free, alloc, free, 5 appels système, pour quelque chose qui devrait pouvoir se faire plus facilement je pense, et si on doit faire ça de façon répétitive pour les 35K fichiers la fragmentation mémoire risque d'être conséquente à force).