M a écrit 2999 commentaires

Ben c'est portable c'est que t'affiche pas la bonne valeur : ce que t'as voulu modifier c'est le premier octet et pas l'entier.

Donc si t'as char *p = px; et t'affiche le contenu de *p ca sera le meme...

Bon reprenons :
Imaginons que j'ai une zone de memoire contenant des donnees :
la taille coder sur 1 octet,
l'info y est coder sur 2 octets
l'info z est coder sur 4 octets

int *i = debut de la zone memoire
(char)*i = taille;
(uint16)*i = htons(y);
*i = htonl(z);

Bon apres tu utilise une structure packed si les champs sont fixe, mais c'est pas toujours le cas. La sol propre est de declarer 3 pointeur, un pour chaque type...

pas forcement : (char) *i, ca revient a declarer char *p = i;
Apres vu que t'ecris qu'un octet ca sera la meme chose sur toute les archi, puis si tu ecris par par block de 32 bits (c'est bien pour ca qu'on avais choisi un int*) alors tu peux toujours utiliser des macro du type cpu_le32, htonl qui te fond la conversion suivant les archi...

D'ailleur si cela avait avoir avec la portabilite ca ferait longtemps que ca serait corrige dans certaines distributions multi-archi.

d'ailleurs le systeme de cache de slashdot doit etre ecrit en perl si mes souvenird sont bon.

non je pense qu'il etait dans l'esprit multisesions ou tu n'ecrasse rien (normal puisque ca marche aussi sur des cd non reinscriptible) et tu continue d'ajouter des sesion a la suite et tu peux supprimer des fichiers en ne les mettant pas dans la nouvelle toc (du moins c'est ce que je suppose).

oui c'etait un prog externe (j'ai jamais dis le contraire)

5 ans c'est pas si veux que ca.

l'exemple etait un peu stupide, mais si t'as plutot
int *i;

alors avec (char)*i = 'c' tu ecris que 1 octet en memoire
et avec *i = 'c' tu ecris 4 octets ( c est transforme en int)

si si ca libere l'espace : autrement y aurait aucun interet au machin : ca serait un vulgaire multisession...

Faut dire que sur le coup linux a beaucoup de retard la dessus, ca marchais parfaitement sous windows il y a plus de 5 ans (sous linux y a encore des pb avec des dvd par exemple).

Aujourd'hui avec les clefs usb, vu la lenteur du machin ca devient plus tres interessant...

PS : sous windows on pouvait meme faire mieux : on pouvait compresser le volume et qd on mettait le disque sur une nouvelle machine qui ne supportait pas le format, on voyait une sesion du cd qui contenait un README avec les executable pour lire le machin (je sais pas tres portable...)

Je comprends bien le problème, mais ce que je demandais, c'est pourquoi les changement apportés entre Gcc 3 et Gcc 4 n'ont pas été fait "tout de suite" pour la version 3.

Pour laisser le temps aux developpeurs de corriger les pb :
gcc 3 : attention : use of cast expressions as lvalues is deprecated
gcc 4 : error: invalid lvalue in assignment

on parle de gcc, pas de g++, donc pas de c++.

De plus les commentaire a la C sont suporte dans le standard C99, donc pas de probleme...

Le probleme viennet plus de certaines magouilles tel que :

int i;
(char)i = 'c'

sur les vielles version de g++ (3.3-) c'etait pire, des oublis de << provoquait des internal errors...

Et ils ne pourraient pas faire "tout de suite" une version moins tolérantes, plutôt que changer un peu à chaque release ? Il y a déjà des projets qui ne compilent qu'avec un Gcc 2.XX ou 3.XX, s'il faut encore différencier entre gcc3.XX et Gcc 4.XX, j'imagine le casse-tête pour ceux qui font des distributions.
Si tout le monde respectait les standards et ne jouait pas avec certaines features, ca serait beaucoup moins problematique...

Par contre pour la comp binaire tu parle de quoi ?
Pour le C il me semble que ca pas changer depuis tres longtemps, pour le c++ ca commence a etre bien stabilisee...

Quelqu'un serait il quelle est la difference avec http://www.asterisk.org/(...) ?

c'est ce qui me semblait aussi avoir compris...
il me semble que j'avais vu ca sur /. (http://slashdot.org/article.pl?sid=05/04/07/1319259&tid=162&(...) )

tu devrais poser ta question sur la ml icewm, tu aurais plus de succes...

Pour mes cours je dois faire de l'assembleur motorola 68k, notre prof nous a indiqué deux programmes qui permettent de compiler et de debugger.

Tu veux dire que les programmes compile tourne sous windows ?

Le debugger serait aussi un emulateur ?

[ ] Autre: préciser ........
Elle est au fond du placard

C'est marrant il publie les sources apres que les drivers aient ete RE....

M'enfin c'est pas la premiere fois que via libere ces driver (cf carte graphique de portable) et si ca peu aider certains...

non...
Le tuner est different et puis ensuite tu recoit des donne compresse...

j'ai retrouve le lien : http://arch.debian.org/docs/linux/html/tlalinux.limitations.html(...)

. In fact, Linus has already begun working on a simplistic tool that takes advantage of Linux performance features. This effort has been aided by Larry, who added that it was also good for BitMover, as a Linux-only tool would not be competition to BitKeeper, whose largest market is on Windows.

Ca ce trouve il va se faire sa moulinette, un peu comme il avait avec sparse...

Il serait ptet temps de migrer vers tla/baz/baz-ng :)
D'apres ce que j'avais vu sur un site proposant une archive tla du noyau linux (heberger par debian si mes souvenirs sont bon), tla est tres lent et mal adapte pour les gros projet avec plein de changesets (64,000 pour linux d'apres l'article). De plus il me semble qu'il ne gerait pas de cache.

Ca a peut etre changer...

Est-ce vraiment le cas ?

ca depend ce que tu compile, ca reduit un peu les acces disque mais faut vraiment qu'il y ai plein de petit fichier pour que ce soit visible, surtout que gcc a une option --pipe..

Si oui est-ce bien dans /dev/shm/ qu'il faut le monter (c'est là qu'il se met tout seul) ?

Non celui la sert pour les commende posix shmopen,...

Il faut que tu le monte ou son stocker tes fichier temporaire de compil ( /tmp ?)

Non ca ne reserve pas de mem, mais par contre si y a des fichiers dessus ca te la bouffe...