Le problème dans tout ça c que si jamais quelque chose (coupure de courant, programme qui plante, os qui plante, …) foire au milieu de la modification du fichier, y'a un fort risque qu'une partie (au moins) des données soit perdue.
Bon, y'a quand même un moyen pas trop tordu ni compliqué pour sécuriser ça mais il faut y penser

Même si c'était dans la libc, ce ne serait quand-même pas garanti atomique (même fwrite ne l'est pas).

(merde, j'aurais dû préciser dans la partie de "la libc portée sur TI" )

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é.)

Ah mais il n'a pas dit que le fichier n'était pas archivé, hein

Bah, alors il doit le désarchiver d'abord s'il veut y écrire, évidemment.

En fait, je cherchais une solution 100% portable

je crois que tu vas avoir du mal sans réécrire le fichier à coté avant de supprimer l'ancien (ce qui demande le double de mémoire, oui oui)

J'en étais arrivé à cette conclusion, tout en me disant "aller, ya bien un truc que j'ai pas du voir"

La boucle de fwrite et fread pour déplacer le contenu du fichier est 100% portable.

Bon, ya une manière de faire de gcc que je ne comprends pas du tout...
J'ai une fonction C :

/**	CompareStrings 
  * 
  *	Check if the string RefString terminated by a char of SeparatorTable is contained in the string table StringTable 
  *	Return #item in the table, or -1 if the string isn't in the table. First item is #0 
  *	Put in *NextChar a ptr to the next char after RefString if NextChar != NULL 
  **/ 
 
short CompareStrings(const char **NextChar, const char *RefString, const char *StringTable, const char *SeparatorTable) 
{ 
// TODO 
// This function could be optimized a lot, comparing char by char the two strings, 
// and checking SeparatorTable if they match and *StringTable == 0. 
// Here the StringTable is read twice, which is not optimal, but it's easier to write. 
 
	const char *EndChar; 
	const char *Separator; 
	short Item = 0; 
	unsigned long length; 
 
	while (*StringTable) 
	{ 
		length = strlen(StringTable); 
		if (!strncmp(RefString, StringTable, length)) 
		{ 
			EndChar = RefString + length; 
			Separator = SeparatorTable; 
			do 
			{ 
				if (*Separator == *EndChar) 
				{ 
					if (NextChar != NULL) 
						*NextChar = EndChar; 
					return Item; 
				} 
			} while (*Separator++); 
		} 
		StringTable += length + 1; 
		Item++; 
	} 
	return -1; 
}

qui donne ça en assembleur :

	movm.l #0x1e30,-(%sp) 
	move.l 28(%sp),%a3 
	move.l 32(%sp),%d5 
	move.l 36(%sp),%a2 
	move.l 40(%sp),%d6 
	clr.w %d4 
	jbra .L2 
.L3: 
	move.l %a2,-(%sp) 
	jsr _ROM_CALL_27E:l 
	move.l %d0,%d3 
	move.l %d0,-(%sp) 
	move.l %a2,-(%sp) 
	move.l %d5,-(%sp) 
	jsr _ROM_CALL_272:l 
	lea (16,%sp),%sp 
	tst.w %d0 
	jbne .L4 
	move.l %d5,%a1 
	add.l %d3,%a1 
	move.b (%a1),%d1 
	move.l %d6,%a0 
.L6: 
	move.b (%a0),%d0 
	cmp.b %d0,%d1 
	jbne .L7 
	cmp.w #0,%a3 
	jbeq .L15 
	move.l %a1,(%a3) 
.L15: 
	move.w %d4,%d0 
	jbra .L11 
.L7: 
	tst.b %d0 
	jbeq .L4 
	addq.l #1,%a0 
	jbra .L6 
.L4: 
	lea 1(%a2,%d3.l),%a2 
	addq.w #1,%d4 
.L2: 
	tst.b (%a2) 
	jbne .L3 
	moveq #-1,%d0 
.L11: 
	movm.l (%sp)+,#0xc78 
	rts

Comme on peut voir, le if (NextChar != NULL) est traduit en cmp.w #0,%a3
Pourquoi un cmp.w ? Si l'adresse que je passe pointe vers $10000, ça fait quoi ? Alors qu'un move.l %a3,%d0 eût été plus petit (-2 octets), et peut-être plus rapide
Là, j'avoue que je capte pas du tout... (tout le reste me semble bien compilé)

C’est interdit de regarder sous le capot
Il me semble que dans l’instruction cmp.w #0, %a3, le .w ne porte que sur la première opérande, la valeur immédiate #0, valeur qui sera étendue sur 32 bits avant d’être comparée à la valeur du registre a3
Donc tout va bien !

(sinon pourquoi tu mixes lowerCamelCase et UpperCamelCase dans tes noms de variables ? Perso je préfère une convention différente pour les noms de variables et de fonctions, pour les différencier au premier coup d’œil)

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) ?

Non, ça ne changerait rien, on écrase %d0.w deux lignes plus loin, c'est la valeur de retour.

Sasume (./370) :
(sinon pourquoi tu mixes lowerCamelCase et UpperCamelCase dans tes noms de variables ? Perso je préfère une convention différente pour les noms de variables et de fonctions, pour les différencier au premier coup d’œil)

Bien vu, une erreur

Ouais enfin, on peut faire tst.l %a3 aussi. cmp.w, c'est naze pour le coup.

EDIT : cross

Tiens 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...

Zerosquare (./374) :
Ouais enfin, on peut faire tst.l %a3 aussi. cmp.w, c'est naze pour le coup.

EDIT : cross

Non, marche pas sur les an.
ADDRESSMETHODS: Dn, (An), (An)+, -(An), x(An), x(An,xr.s), x.w, x.l (68kguide)
D'ailleurs des fois c'est bien chiant, mais j'utilise toujours un move.l an,dn, c'est le plus court/rapide que j'ai trouvé

Exact, mea culpa.

Il vaut mieux éviter de regarder le code produit par GCC si on est sensible à ce genre de choses.

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.

C'est aussi surtout que le backend 68k n'est pas super bien maintenue.

Lionel Debroux (./380) :
Le compilo d'Intel est meilleur que GCC pour les x86 Intel.

Vrai sur X86. Faux sur AMD64:
http://multimedia.cx/eggs/64-bit-gcc-icc-performance-round/
http://multimedia.cx/eggs/last-performance-smackdown-for-awhile/
http://multimedia.cx/eggs/compiler-smackdown-2010-1-64-bit/
Il semblerait que ICC en 64 bits soit assez loin de ce que faisait son petit frère.

En effet, on voit clairement que les playmate GCC y sont pour quelque chose

Je ne connaissais pas ce benchmark. En 32 bits, c'est amusant que LLVM, projet beaucoup plus récent (mais avec une architecture plus moderne...) que GCC, arrive à faire mieux que GCC. Il fait d'ailleurs également mieux que les ICC récents...

./382: ttk

Lionel Debroux (./383) :
Je ne connaissais pas ce benchmark. En 32 bits, c'est amusant que LLVM, projet beaucoup plus récent (mais avec une architecture plus moderne...) que GCC, arrive à faire mieux que GCC. Il fait d'ailleurs également mieux que les ICC récents...

Je n'ai pas vu de bench sur llvm en 32 bits. Juste en 64 bits. Mais j'avoue que j'ai étais surpris de ces résultats. Mon expérience personnelle n'est pas plutôt bonne à son sujet.

J'ai écrit cette fonction :

/** SkipSpaces 
  * 
  * Skip spaces and horizontal tabs. Return a pointer to the next non-space char, or to EOF 
  */ 
const char *SkipSpaces(const char *Ptr) 
{ 
  while (*Ptr && (*Ptr != EOL) && ((*Ptr++ == SPACE) || (*Ptr == HTAB))); 
  return Ptr; 
}

Est-ce que ça va bien passer tous les espaces/htab et pointer sur le premier caractère suivant ? Et renvoyer un pointeur sur un caractère nul ou EOL si on y arrive ?
Parce que pour moi ça marche tel que c'est, sauf si le compilateur s'amuse à inverser l'ordre des conditions. J'aimerais savoir si une implémentation peut mettre ce code au tapis.

J'utilise cette écriture parce que je gagne deux octets par rapport à une écriture plus naïve. Je vous emmerde.

&& 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.

Ah, donc le ++ est fait avant le (*Ptr == HTAB) ? Je pensais qu'il était fait à la fin de l'évaluation complète de la condition dans son ensemble Et ok pour le *Ptr, j'ai changé mon écriture et je l'ai oublié

Donc au final ça donne ça pour moi :

	while ((*Ptr != EOL) && ((*Ptr++ == SPACE) || (*Ptr == HTAB)));

Folco (./387) :
Ah, donc le ++ est fait avant le (*Ptr == HTAB) ?

Oui, il est fait avant le prochain sequence point, qui est ||.

Kevin Kofler (./388) :
Oui, il est fait avant le prochain sequence point, qui est ||.

Erf zut... (sinon oui, j'ai multi-cross-édité)