Concatenation de chaine de caractere

Et ? Je ne vois pas le rapport. Marc accuse GNU d'être une agence de
vaporwares, alors que le projet GNU est tout de même l'un de ceux qui
ont apporté le plus au monde du libre (et bon nombre d'outils GNU sont
utilisés aussi sur les BSD d'ailleurs (gcc, gdb, emacs, the gimp,
...))

vu que c'est eux qui ont inventé le concept du libre, je ne vois pas
comment ça pourrait être quelqu'un d'autre qui ait apporté le plus.
C'est également Arsunik qui a apporté le plus au monde du cocktail BZH.

--
DINH V. Hoa,

etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan

espie@tetto.gentiane.org (Marc Espie) writes:

| In article <m3y8u5pha3.fsf@uniton.integrable-solutions.net>,
| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| >| Emacs, gcc, gdb, des fileutils et coreutils très complets, bison,
| >| flex, info, The Gimp, Gnome, une libc, ... c'est sûr que GNU ne sort
| >| que peu de choses concrètes.
|
| >et tu crois que Marc n'a contribué à aucun de ses produits ?
|
| Je revendique haut et fort le fait de ne rien avoir jamais ecrit dans
| emacs.

je savais pour emacs (le contraire aurait été étonnant ;-p)

-- Gaby

kilobug@freesurf.fr (Gaël Le Mignot) writes:

| > | > J'appelerai bien ca le mirage GNU, tiens. Toujours courir apres les
| > | > dernieres nouveautes est une assez bonne facon de s'assurer qu'on ne
| > | > sortira jamais rien de concret.
| > |
| > | Emacs, gcc, gdb, des fileutils et coreutils très complets, bison,
| > | flex, info, The Gimp, Gnome, une libc, ... c'est sûr que GNU ne sort
| > | que peu de choses concrètes.
|
| > et tu crois que Marc n'a contribué à aucun de ses produits ?
|
| Et ? Je ne vois pas le rapport.

c'est probablement ça le problème.

| Marc accuse GNU d'être une agence de
| vaporwares, alors que le projet GNU est tout de même l'un de ceux qui
| ont apporté le plus au monde du libre (et bon nombre d'outils GNU sont
| utilisés aussi sur les BSD d'ailleurs (gcc, gdb, emacs, the gimp,
| ...))

et alors ? Tu ne connais pas la critique ?

Je suis l'un des Release Manager de GCC et cela ne m'empêche pas de le
fustiger à l'occasion.

-- Gaby

kilobug@freesurf.fr (Gaël Le Mignot) écrivait :

Ce serait pas mal d'essayer d'éviter de donner de mauvaises habitudes en
conseillant l'utilisation de fonctions (vraiment) non-standards. Je sais
bien que ces fonctions sont pratiques mais vu qu'elles n'existent
souvent que sur une plateforme unique (Linux et GNU), ce n'est pas
l'idéal.

Lorsque les fonctions sont ddans une bibliothèque diffusé sous une
license libre, et que tu comptes diffuser le programme sous une
license compatibel, tu peux reprendre le code déjà fait, testé, validé
et optimisé de la libc GNU ou de la GLib, plutôt que de réinventer la
roue à chaque fois.

Juste un doigt de proselytisme. Il existe une licence libre (BSD) qui
se fonde sur des ideaux philosophiques differents de ceux de la GPL.

Oui, des idéaux de jemenfoutisme, de "oh bah qu'ils reprennent mon
code pour accroitre leur puissance commerciale afin de mieux
vérouiller l'informatique dans les brevets et du TCPA", très peu pour
moi, merci. Je ne comprends pas comment des auteurs de logiciel libre
peuvent trouver normal de laisser leur code se faire piller par des
gens qui déclarent officilement que le logiciel libre est un ennemi à
abattre.

Sans TCP-IP sous licence BSD aurait-on internet aujourd'hui ? À mon
avis non...

kilobug@freesurf.fr (Gaël Le Mignot) wrote in message news:<plopm3he0ut4n9.fsf@drizzt.kilobug.org>...

Par exemple, en embarqué, ils ne travaillent que sur des données
allouées statiquement, devine pourquoi ? (des indices ont été
données dans la première partie de ce paragraphe).

Parce qu'ils n'ont pas forcément d'implémentation de malloc ? ou
d'implémentation efficace de malloc ? Avoir un malloc efficace, ça
demande une infrastructure assez complexe. De plus, malloc n'est pas
déterliniste en temps d'exécution (si unb appel moyen à malloc est
assez rapide, certains appels à malloc peuvent être long). Mais bon,
on parle d'un cas très particulier là.

je travaille sur microcontrôleurs et je peux te dire pourquoi on
n'utilise pas malloc dans nos projets.

La raison est surtout une raison de sécurité : dans l'embarqué,
l'ennemi n'est pas forcément le hackeur (le logiciel peut tourner de
façon isolé), mais le programmeur (soi-même).
Un buffer sur pile est TOUJOURS désalloué quand on sort d'une
fonction, alors qu'un malloc, si aucun free n'est fait, constitue une
fuite de mémoire qui finit par être préjudiciable, et là, personne
pour relancer la machine (on met quand même toujours en place des
dispositifs de sécurité).
Par expérience, il y a toujours un free qui est oublié quelque part
dans le code donc l'usage de malloc/free est banni. A la place, toute
fonction qui prend un buffer en argument doit aussi prendre en
argument sa taille (pas d'utilisation de sprintf, mais d'un équivalent
à snprintf par exemple) et tester la taille des données à écrire dans
le buffer par rapport à la taille du buffer. Il faut surtout faire
attention à ne pas confondre la taille d'une chaîne avec la taille du
buffer.

Enfin, le malloc, en tant que standard C, peut être générateur de
"gruyère" : à force d'allocation et de libération de mémoire on peut
se retrouver avec au total assez de mémoire pour allouer une donnée
sans avoir assez de mémoire contiguë pour le faire. Le système de
gestion de la mémoire ne peut pas "tasser" la mémoire utilisée pour
libérer un espace libre plus grand car il ne connaît pas l'adresse des
pointeurs sur les zones mémoire qu'il déplacerait.

HalfWolf

je travaille sur microcontrôleurs et je peux te dire pourquoi on
n'utilise pas malloc dans nos projets.

La raison est surtout une raison de sécurité : dans l'embarqué,
l'ennemi n'est pas forcément le hackeur (le logiciel peut tourner de
façon isolé), mais le programmeur (soi-même).

C'est vrai

Un buffer sur pile est TOUJOURS désalloué quand on sort d'une
fonction, alors qu'un malloc, si aucun free n'est fait, constitue une
fuite de mémoire qui finit par être préjudiciable, et là, personne
pour relancer la machine (on met quand même toujours en place des
dispositifs de sécurité).

En effet, c'est un problème du malloc

Enfin, le malloc, en tant que standard C, peut être générateur de
"gruyère" : à force d'allocation et de libération de mémoire on peut
se retrouver avec au total assez de mémoire pour allouer une donnée
sans avoir assez de mémoire contiguë pour le faire. Le système de
gestion de la mémoire ne peut pas "tasser" la mémoire utilisée pour
libérer un espace libre plus grand car il ne connaît pas l'adresse des
pointeurs sur les zones mémoire qu'il déplacerait.

Ça dépend de l'implémentation de malloc et du système. Avec un malloc
comme le malloc GNU sous Unix, il utilise automatiquement mmap() pour
allouer de grosses mémoires, et grace à la magie de la pagination, il
n'y a aucun problème de fragmentation avec mmap().

Le problème est toujours présent pour les petites quantités de mémoire,
mais en pratique se pose beaucoup moins.

Maintenant, sur l'embarqué (où la mémoire disponible est faible, et où
il n'y a souvent pas de MMU), ça doit en effet être un vrai problème.

--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org

Enfin, le malloc, en tant que standard C, peut être générateur de
"gruyère" : à force d'allocation et de libération de mémoire on peut
se retrouver avec au total assez de mémoire pour allouer une donnée
sans avoir assez de mémoire contiguë pour le faire. Le système de
gestion de la mémoire ne peut pas "tasser" la mémoire utilisée pour
libérer un espace libre plus grand car il ne connaît pas l'adresse des
pointeurs sur les zones mémoire qu'il déplacerait.

Ça dépend de l'implémentation de malloc et du système. Avec un malloc
comme le malloc GNU sous Unix, il utilise automatiquement mmap() pour
allouer de grosses mémoires, et grace à la magie de la pagination, il
n'y a aucun problème de fragmentation avec mmap().

Le gruyère dont il parlait ne concernait pas plus les grosses
quantités de mémoire que les petites. Je ne vois d'ailleurs pas en quoi
mmap() aide plus ...

Bref, que ce soit avec l'implémentation GNU ou autre (j'ai
l'impression que tu essaies un peu d'endoctriner tout le monde avec
GNU), je pense qu'avec des allocations donné dans l'exemple suivant, ça
devient vite problématique. On a une perte de 33% de mémoire avec
l'implémentation GNU en question (glibc 2.3.2 de chez Debian).

En conclusion, on ne fait pas la publicité pour un produit sur des
qualités qu'il n'a pas, car les gens s'en apercoivent très vite en
vérifiant.


-- séquence de test --

$ ./toto.x
taille 10019K, taille prévue 15009K => perte 33 %

$ pmap 26636
26636: ./toto.x
08048000 4K read/exec /net/home/dinh/tmp/toto.x
08049000 4K read/write /net/home/dinh/tmp/toto.x
0804a000 15264K read/write/exec [ anon ] <= on a le tas ici.
... je passe le reste, inintéressant ...


-- memory-killer.c --

#include <stdio.h>
#include <stdlib.h>

#define SIZE_1 1024
#define SIZE_2 (SIZE_1 / 2) + 1

int main(void)
{
int i;
int size;
int estimated;

size = 0;
estimated = 0;

for(i = 0 ; i < 10000 ; i ++) {
void * a;
void * b;
void * c;
void * d;

a = malloc(SIZE_1);
size += SIZE_1;

b = malloc(SIZE_1);
size += SIZE_1;

free(b);
size -= SIZE_1;
d = malloc(SIZE_2);
size += SIZE_2;

/* d vient prendre la place de b */
if (b != d)
printf("attention, b != d %p %pn", b, d);

free(a);
size -= SIZE_1;
c = malloc(SIZE_2);
size += SIZE_2;

/* c vient prendre la place de a */
if (c != a)
printf("attention, a != c %p %pn", a, c);

estimated += SIZE_1 + SIZE_2;
}

if (i % 1000 == 0) {
printf("taille %iK, taille prévue %iK => perte %i %%n",
size / 1024, estimated / 1024,
(estimated - size) * 100 / estimated);
getchar();
}

return 0;
}

--
DINH V. Hoa,

etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan

"Gaël Le Mignot" <kilobug@freesurf.fr> a écrit dans le message news:
plopm3ptff9nxe.fsf@drizzt.kilobug.org...

je travaille sur microcontrôleurs et je peux te dire pourquoi on
n'utilise pas malloc dans nos projets.

La raison est surtout une raison de sécurité : dans l'embarqué,
l'ennemi n'est pas forcément le hackeur (le logiciel peut tourner de
façon isolé), mais le programmeur (soi-même).

C'est vrai

Pas vraiment d'accord, il suffit d'avoir confiance dans l'équipe de
développement et de tests...

Un buffer sur pile est TOUJOURS désalloué quand on sort d'une
fonction, alors qu'un malloc, si aucun free n'est fait, constitue une
fuite de mémoire qui finit par être préjudiciable, et là, personne
pour relancer la machine (on met quand même toujours en place des
dispositifs de sécurité).

En effet, c'est un problème du malloc

Et alors... Il existe un certain nombre de moyen contre ça: le premier,
se réécrire un malloc() / free() avec compteur, un autre moyen
est de passer par Purify (ou un autre truc du genre)...

Enfin, le malloc, en tant que standard C, peut être générateur de
"gruyère" : à force d'allocation et de libération de mémoire on peut
se retrouver avec au total assez de mémoire pour allouer une donnée
sans avoir assez de mémoire contiguë pour le faire. Le système de
gestion de la mémoire ne peut pas "tasser" la mémoire utilisée pour
libérer un espace libre plus grand car il ne connaît pas l'adresse des
pointeurs sur les zones mémoire qu'il déplacerait.

Ça dépend de l'implémentation de malloc et du système. Avec un malloc
comme le malloc GNU sous Unix, il utilise automatiquement mmap() pour
allouer de grosses mémoires, et grace à la magie de la pagination, il
n'y a aucun problème de fragmentation avec mmap().

Le problème est toujours présent pour les petites quantités de mémoire,
mais en pratique se pose beaucoup moins.

Maintenant, sur l'embarqué (où la mémoire disponible est faible, et où
il n'y a souvent pas de MMU), ça doit en effet être un vrai problème.

Effectivement, ça dépend du gestionaire mémoire et de l'algorithme
retenu pour la gestion des blocks mémoire.

Quant à l'embarqué, n'oublions pas que les capacités vont quand même
en croissant (pas autant que les PC, par exemple), mais ça augmente
quand même...


Pascal
http://je_nai_pas_dadresse.fr
GSM: ça sert à rien
ICQ: moi aussi, I see you
Et fingerprint dans le c...
Membre: je suis un membre de ma famille, c'est le plus important :)

Pascal
http://je_nai_pas_dadresse.fr
GSM: ça sert à rien
ICQ: moi aussi, I see you
Et fingerprint dans le c...
Membre: je suis un membre de ma famille, c'est le plus important :)

tu feras attention, ta signature dépasse les 4 lignes autorisée
suivant le standard d'utilisation (nettiquette ?) des groupes de
discussion (Usenet).

--
DINH V. Hoa,

etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan

Enfin, le malloc, en tant que standard C, peut être générateur de
"gruyère" : à force d'allocation et de libération de mémoire on peut
se retrouver avec au total assez de mémoire pour allouer une donnée
sans avoir assez de mémoire contiguë pour le faire. Le système de
gestion de la mémoire ne peut pas "tasser" la mémoire utilisée pour
libérer un espace libre plus grand car il ne connaît pas l'adresse des
pointeurs sur les zones mémoire qu'il déplacerait.

Ça dépend de l'implémentation de malloc et du système. Avec un malloc
comme le malloc GNU sous Unix, il utilise automatiquement mmap() pour
allouer de grosses mémoires, et grace à la magie de la pagination, il
n'y a aucun problème de fragmentation avec mmap().

Le gruyère dont il parlait ne concernait pas plus les grosses
quantités de mémoire que les petites. Je ne vois d'ailleurs pas en
quoi mmap() aide plus ...

La fragmentation, en pratique, se fait d'autant plus sentir que les
écarts de taille entre les blocs sont gros (de manière générale)

Pour mmap, mmap ne crée pas de fragmentation, par son fonctionnement
même. On a une perte de mémoire vu que la granularité de mmap est
celle d'une page (4096 octets sur ia-32), mais sur des grosses
quantatités de mémoire, la perte est négligeable (sur 1Mo, elle est au
pire de 0.4%)

Bref, que ce soit avec l'implémentation GNU ou autre (j'ai
l'impression que tu essaies un peu d'endoctriner tout le monde avec
GNU),

Non, je parle de ce que je connais. J'ai lu le malloc de la libc GNU,
mais je n'ai pas lu d'autres malloc, donc je ne parle que du malloc
GNU.

Je devrais faire quoi ? Parler dans le vent sans me référer à quelque
chose de concret ? Ou parler de ce que je connais pas ?

je pense qu'avec des allocations donné dans l'exemple suivant, ça
devient vite problématique. On a une perte de 33% de mémoire avec
l'implémentation GNU en question (glibc 2.3.2 de chez Debian).

On a une perte de 33% avec toute implémentation sur un système n'ayant
pas de pagination suffisament fine avec ce code là, en effet. Mais tu
avoueras que ce code est vraiment un cas d'école.

Oui, il existe des cas où malloc (où n'importe quel malloc) gaspille
de la mémoire à cause du phénomène gruyère. Maintenant, dans la
pratique, il y a très peu de cas où ce gaspillage est important, et la
plupart de ces cas se font avec des gros blocs de mémoire, d'où
l'intéret d'utiliser mmap.

En conclusion, on ne fait pas la publicité pour un produit sur
des qualités qu'il n'a pas, car les gens s'en apercoivent très vite
en vérifiant.

Un produit ? De la publicité ?

--
Gael Le Mignot "Kilobug" - kilobug@nerim.net - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA

Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org