Même si c'était dans la libc, ce ne serait quand-même pas garanti atomique (même fwrite ne l'est pas).
Sur TI, la méthode du mmap n'est pas mal, sauf que tu utilises les fonctions de vat.h pour avoir accès à l'adresse des données, pas mmap. (Et c'est probablement la plateforme où memmove est plus efficace qu'une copie par blocs. Enfin, probablement aussi pour un ramdisk GNU/Linux, remarque. L'idée, c'est que le fichier est en RAM, du coup memmove est adapté.)
Bah, alors il doit le désarchiver d'abord s'il veut y écrire, évidemment.
La boucle de fwrite et fread pour déplacer le contenu du fichier est 100% portable.
deleted2 Le 28/02/2010 à 00:50Edité par deleted2 le 28/02/2010 à 01:02 Ah merci, une fois sur deux quand je rate un truc c'est que j'oublie l'extension...
N'empêche que niveau place, c'est pas optimal...
Pas sûr. Un move.l %a3, %d0 écraserait le registre %d0, peut-être qu’il est utilisé (j’ai pas regardé le code) ?
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas
. »
Ouais enfin, on peut faire tst.l %a3 aussi. cmp.w, c'est naze pour le coup.
EDIT : cross
—
Zeroblog —
« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » —
Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » —
GT TurboTiens d'ailleurs, le while (*Separator++); prend 8 octets de plus que while (*Separator);
Je sais pas comment il se démerde là encore, un simple addq... J'ai pas regardé le code, mais de toute façon ça m'épate méchamment...
Concrètement ça veut dire quoi ? GCC n'est pas un bon compilo ? J'ai l'impression qu'il lui faut une optimisation pipole tous les deusx lignes...
GCC est plutôt parmi les bons compilos, mais comme il accepte plusieurs langages source en entrée et plein de plate-formes en sortie, et qu'il manque de flexibilité (la version 4.5, pas encore releasée, améliore ce deuxième point), il ne peut clairement pas être aussi bon que les compilos spécifiques à une plate-forme.
Le compilo d'Intel est meilleur que GCC pour les x86 Intel, le compilo d'ARM est meilleur que GCC pour les ARM, etc.
Kevin Kofler Le 02/03/2010 à 13:42Edité par Kevin Kofler le 02/03/2010 à 13:44 && et || sont des sequence points, donc ton code est valide. (C'est un des rares cas où tu peux faire ça à l'intérieur d'une expression.) Mais il est faux quand-même. Tu testes le mauvais caractère pour HTAB. De plus, ton *Ptr && est redondant, si le caractère est \0, ce n'est ni un espace, ni un tab.
EDIT: J'ai écrit ça avant que tu as ajouté "(*Ptr != EOL) &". Il manque un & là et c'est aussi une condition redondante pour la même raison pour laquelle *Ptr est redondant.