Comment concatener plusieur chaine de caractere, un nombre assez
important? je connais strcat, mais c'est pas tres pratique des que l'on
doit concatener plus de deux chaines... En gros je cherche un equivalent
a ce que l'on trouve sur java ou c++, un truc simple du style
"char1"+"char2"+char3" -> "char1char2char3".
--
Pascal
"Pascal CORBILLON" wrote in message news:<3fc4c8c2$0$9321$...
"Gaël Le Mignot" a écrit dans le message news:
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...
<IRONIE> ... et aussi dans l'environnement du produit qui évitera soigneusement ses bugs. Perso, j'ai tellement confiance dans l'équipe de développement que, quand une modif profonde et majeure a été faite, je la compile directement (sans erreurs du premier coup bien sûr), si il y a des warnings je les laisse car il doit y avoir une bonne raison pour que le développeur les ait laissés et que je l'envoie chez le client sans avoir fait un seul test. </IRONIE>
On a beau faire confiance aux gens, l'erreur est humaine et c'est un facteur à intégrer dans le développement d'un produit si on veut minimiser les risques. Ne pas le prendre en compte c'est se voiler la face et on finit toujours par le payer. Les tests sont nécessaires, mais leur couverture ne peut pas être complète, surtout dans les problèmes d'allocation et libération de la mémoire où une fuite peut mettre des mois avant de conduire à un comportement indésirable du produit.
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)...
Il me semble que tu parles de méthodes où on lance le programme et quand il s'arrête on relève les compteurs ou on lit le diagnostic avec purify. Je travaille sur des programmes qui ne s'arrêtent jamais, ils doivent tourner de façon permanente pendant au moins 10 ans sans jamais s'arrêter. Je vois mal comment on pourrait être sûr que parcequ'il n'y a pas de memory leak après 1 jour, 1 semaine ou 1 mois il n'y en aura pas plus tard. D'où la décision de ne pas utiliser de 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.
Effectivement, ça dépend du gestionaire mémoire et de l'algorithme retenu pour la gestion des blocks mémoire.
Mon microcontrôleur n'a pas de gestionnaire de mémoire : accès directe aux adresses : on ne peut donc pas éviter l'effet "gruyère" avec malloc.
Il y a toujours moyen d'avoir de l'allocation dynamique "safe" en utilisant plutôt une fonction du type : my_malloc(void**, size_t) ou on passerait le pointeur sur le pointeur sur la zone mémoire. De cette façon on pourrait modifier le pointeur sur la zone mémoire lors d'un tassement de la mémoire (lorsqu'il n'y a plus de place), mais il faut faire attention après lors de passage de pointeur de passer des pointeurs sur pointeurs. Il faut aussi faire attention à la préemption qui pourrait changer la valeur du pointeur. Enfin bon, c'est lourd à gérer et donc entraîne des pertes de performances. Mais quand on ne peut pas faire autrement...
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...
Ca dépend de quel embarqué tu parles, je ne parle pas de programmation sous windows CE, ou autre... Notre micro possède 8Ko de RAM.
HalfWolf
"Pascal CORBILLON" <pascal.corbillon@free.fr> wrote in message news:<3fc4c8c2$0$9321$626a54ce@news.free.fr>...
"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...
<IRONIE>
... et aussi dans l'environnement du produit qui évitera soigneusement
ses bugs.
Perso, j'ai tellement confiance dans l'équipe de développement que,
quand une modif profonde et majeure a été faite, je la compile
directement (sans erreurs du premier coup bien sûr), si il y a des
warnings je les laisse car il doit y avoir une bonne raison pour que
le développeur les ait laissés et que je l'envoie chez le client sans
avoir fait un seul test.
</IRONIE>
On a beau faire confiance aux gens, l'erreur est humaine et c'est un
facteur à intégrer dans le développement d'un produit si on veut
minimiser les risques. Ne pas le prendre en compte c'est se voiler la
face et on finit toujours par le payer.
Les tests sont nécessaires, mais leur couverture ne peut pas être
complète, surtout dans les problèmes d'allocation et libération de la
mémoire où une fuite peut mettre des mois avant de conduire à un
comportement indésirable du produit.
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)...
Il me semble que tu parles de méthodes où on lance le programme et
quand il s'arrête on relève les compteurs ou on lit le diagnostic avec
purify.
Je travaille sur des programmes qui ne s'arrêtent jamais, ils doivent
tourner de façon permanente pendant au moins 10 ans sans jamais
s'arrêter. Je vois mal comment on pourrait être sûr que parcequ'il n'y
a pas de memory leak après 1 jour, 1 semaine ou 1 mois il n'y en aura
pas plus tard.
D'où la décision de ne pas utiliser de 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.
Effectivement, ça dépend du gestionaire mémoire et de l'algorithme
retenu pour la gestion des blocks mémoire.
Mon microcontrôleur n'a pas de gestionnaire de mémoire : accès directe
aux adresses : on ne peut donc pas éviter l'effet "gruyère" avec
malloc.
Il y a toujours moyen d'avoir de l'allocation dynamique "safe" en
utilisant plutôt une fonction du type :
my_malloc(void**, size_t)
ou on passerait le pointeur sur le pointeur sur la zone mémoire.
De cette façon on pourrait modifier le pointeur sur la zone mémoire
lors d'un tassement de la mémoire (lorsqu'il n'y a plus de place),
mais il faut faire attention après lors de passage de pointeur de
passer des pointeurs sur pointeurs. Il faut aussi faire attention à la
préemption qui pourrait changer la valeur du pointeur.
Enfin bon, c'est lourd à gérer et donc entraîne des pertes de
performances.
Mais quand on ne peut pas faire autrement...
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...
Ca dépend de quel embarqué tu parles, je ne parle pas de programmation
sous windows CE, ou autre...
Notre micro possède 8Ko de RAM.
"Pascal CORBILLON" wrote in message news:<3fc4c8c2$0$9321$...
"Gaël Le Mignot" a écrit dans le message news:
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...
<IRONIE> ... et aussi dans l'environnement du produit qui évitera soigneusement ses bugs. Perso, j'ai tellement confiance dans l'équipe de développement que, quand une modif profonde et majeure a été faite, je la compile directement (sans erreurs du premier coup bien sûr), si il y a des warnings je les laisse car il doit y avoir une bonne raison pour que le développeur les ait laissés et que je l'envoie chez le client sans avoir fait un seul test. </IRONIE>
On a beau faire confiance aux gens, l'erreur est humaine et c'est un facteur à intégrer dans le développement d'un produit si on veut minimiser les risques. Ne pas le prendre en compte c'est se voiler la face et on finit toujours par le payer. Les tests sont nécessaires, mais leur couverture ne peut pas être complète, surtout dans les problèmes d'allocation et libération de la mémoire où une fuite peut mettre des mois avant de conduire à un comportement indésirable du produit.
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)...
Il me semble que tu parles de méthodes où on lance le programme et quand il s'arrête on relève les compteurs ou on lit le diagnostic avec purify. Je travaille sur des programmes qui ne s'arrêtent jamais, ils doivent tourner de façon permanente pendant au moins 10 ans sans jamais s'arrêter. Je vois mal comment on pourrait être sûr que parcequ'il n'y a pas de memory leak après 1 jour, 1 semaine ou 1 mois il n'y en aura pas plus tard. D'où la décision de ne pas utiliser de 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.
Effectivement, ça dépend du gestionaire mémoire et de l'algorithme retenu pour la gestion des blocks mémoire.
Mon microcontrôleur n'a pas de gestionnaire de mémoire : accès directe aux adresses : on ne peut donc pas éviter l'effet "gruyère" avec malloc.
Il y a toujours moyen d'avoir de l'allocation dynamique "safe" en utilisant plutôt une fonction du type : my_malloc(void**, size_t) ou on passerait le pointeur sur le pointeur sur la zone mémoire. De cette façon on pourrait modifier le pointeur sur la zone mémoire lors d'un tassement de la mémoire (lorsqu'il n'y a plus de place), mais il faut faire attention après lors de passage de pointeur de passer des pointeurs sur pointeurs. Il faut aussi faire attention à la préemption qui pourrait changer la valeur du pointeur. Enfin bon, c'est lourd à gérer et donc entraîne des pertes de performances. Mais quand on ne peut pas faire autrement...
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...
Ca dépend de quel embarqué tu parles, je ne parle pas de programmation sous windows CE, ou autre... Notre micro possède 8Ko de RAM.
HalfWolf
espie
In article , HalfWolf wrote:
Il me semble que tu parles de méthodes où on lance le programme et quand il s'arrête on relève les compteurs ou on lit le diagnostic avec purify. Je travaille sur des programmes qui ne s'arrêtent jamais, ils doivent tourner de façon permanente pendant au moins 10 ans sans jamais s'arrêter. Je vois mal comment on pourrait être sûr que parcequ'il n'y a pas de memory leak après 1 jour, 1 semaine ou 1 mois il n'y en aura pas plus tard. D'où la décision de ne pas utiliser de malloc. On peut faire plus fin que de betes compteurs. Par exemple, avoir un
malloc etendu, qui en mode debug, tagge les allocations avec des annotations judicieusement choisies. Sur un programme qui tourne pendant tres longtemps, on verifie de temps en temps que les allocations correspondent bien a ce qui devrait etre (soit manuellement, soit de maniere programmee). Allie a des tests de couverture, ca donne quand meme de tres bonnes techniques pour verifier qu'il n'y a pas de fuites de memoire.
Moi ce qui me gene plus, c'est ce cote `Graal' des fuites memoire. On a parfois l'impression que c'est la seule et unique source de bugs dans les programmes. Alors que ce n'est jamais qu'une ressource comme les autres, et que tout probleme d'allocation/desallocation dans une quelconque de ces ressources peut planter.
Bien sur, dans l'embarque, avoir un controle extremement precis sur chacune des ressources que l'on peut requisitionner est indispensable. En pre-calculer une bonne partie, voire se debarrasser de tous les aspects dynamiques qu'on peut. Dans certains cas, effectivement, on peut se retrouver avec des programmes sans aucun malloc... et dans les cas restants, il faut une analyse correcte de ce qu'on fait.
In article <1a759353.0311271116.f527e5a@posting.google.com>,
HalfWolf <halfwolf@free.fr> wrote:
Il me semble que tu parles de méthodes où on lance le programme et
quand il s'arrête on relève les compteurs ou on lit le diagnostic avec
purify.
Je travaille sur des programmes qui ne s'arrêtent jamais, ils doivent
tourner de façon permanente pendant au moins 10 ans sans jamais
s'arrêter. Je vois mal comment on pourrait être sûr que parcequ'il n'y
a pas de memory leak après 1 jour, 1 semaine ou 1 mois il n'y en aura
pas plus tard.
D'où la décision de ne pas utiliser de malloc.
On peut faire plus fin que de betes compteurs. Par exemple, avoir un
malloc etendu, qui en mode debug, tagge les allocations avec des
annotations judicieusement choisies. Sur un programme qui tourne pendant
tres longtemps, on verifie de temps en temps que les allocations
correspondent bien a ce qui devrait etre (soit manuellement, soit de
maniere programmee). Allie a des tests de couverture, ca donne quand meme
de tres bonnes techniques pour verifier qu'il n'y a pas de fuites de
memoire.
Moi ce qui me gene plus, c'est ce cote `Graal' des fuites memoire.
On a parfois l'impression que c'est la seule et unique source de bugs
dans les programmes. Alors que ce n'est jamais qu'une ressource comme
les autres, et que tout probleme d'allocation/desallocation dans une
quelconque de ces ressources peut planter.
Bien sur, dans l'embarque, avoir un controle extremement precis sur chacune
des ressources que l'on peut requisitionner est indispensable. En
pre-calculer une bonne partie, voire se debarrasser de tous les aspects
dynamiques qu'on peut. Dans certains cas, effectivement, on peut se
retrouver avec des programmes sans aucun malloc... et dans les cas
restants, il faut une analyse correcte de ce qu'on fait.
Il me semble que tu parles de méthodes où on lance le programme et quand il s'arrête on relève les compteurs ou on lit le diagnostic avec purify. Je travaille sur des programmes qui ne s'arrêtent jamais, ils doivent tourner de façon permanente pendant au moins 10 ans sans jamais s'arrêter. Je vois mal comment on pourrait être sûr que parcequ'il n'y a pas de memory leak après 1 jour, 1 semaine ou 1 mois il n'y en aura pas plus tard. D'où la décision de ne pas utiliser de malloc. On peut faire plus fin que de betes compteurs. Par exemple, avoir un
malloc etendu, qui en mode debug, tagge les allocations avec des annotations judicieusement choisies. Sur un programme qui tourne pendant tres longtemps, on verifie de temps en temps que les allocations correspondent bien a ce qui devrait etre (soit manuellement, soit de maniere programmee). Allie a des tests de couverture, ca donne quand meme de tres bonnes techniques pour verifier qu'il n'y a pas de fuites de memoire.
Moi ce qui me gene plus, c'est ce cote `Graal' des fuites memoire. On a parfois l'impression que c'est la seule et unique source de bugs dans les programmes. Alors que ce n'est jamais qu'une ressource comme les autres, et que tout probleme d'allocation/desallocation dans une quelconque de ces ressources peut planter.
Bien sur, dans l'embarque, avoir un controle extremement precis sur chacune des ressources que l'on peut requisitionner est indispensable. En pre-calculer une bonne partie, voire se debarrasser de tous les aspects dynamiques qu'on peut. Dans certains cas, effectivement, on peut se retrouver avec des programmes sans aucun malloc... et dans les cas restants, il faut une analyse correcte de ce qu'on fait.
Gabriel Dos Reis
(Marc Espie) writes:
| Moi ce qui me gene plus, c'est ce cote `Graal' des fuites memoire. | On a parfois l'impression que c'est la seule et unique source de bugs | dans les programmes. Alors que ce n'est jamais qu'une ressource comme | les autres, et que tout probleme d'allocation/desallocation dans une | quelconque de ces ressources peut planter.
c'est quand mêne plus facile de vendre un logiciel estampillé détecteur de fuite que de vendre un programmeur estampillé pisseur de codes sans bug. Non ?
-- Gaby
espie@tetto.gentiane.org (Marc Espie) writes:
| Moi ce qui me gene plus, c'est ce cote `Graal' des fuites memoire.
| On a parfois l'impression que c'est la seule et unique source de bugs
| dans les programmes. Alors que ce n'est jamais qu'une ressource comme
| les autres, et que tout probleme d'allocation/desallocation dans une
| quelconque de ces ressources peut planter.
c'est quand mêne plus facile de vendre un logiciel estampillé
détecteur de fuite que de vendre un programmeur estampillé pisseur de
codes sans bug. Non ?
| Moi ce qui me gene plus, c'est ce cote `Graal' des fuites memoire. | On a parfois l'impression que c'est la seule et unique source de bugs | dans les programmes. Alors que ce n'est jamais qu'une ressource comme | les autres, et que tout probleme d'allocation/desallocation dans une | quelconque de ces ressources peut planter.
c'est quand mêne plus facile de vendre un logiciel estampillé détecteur de fuite que de vendre un programmeur estampillé pisseur de codes sans bug. Non ?
-- Gaby
espie
In article , Gabriel Dos Reis wrote:
c'est quand mêne plus facile de vendre un logiciel estampillé détecteur de fuite que de vendre un programmeur estampillé pisseur de codes sans bug. Non ?
Oui, il n'y a qu'a voir le succes de Java compare a C++ :)
In article <m3r7ztee8n.fsf@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
c'est quand mêne plus facile de vendre un logiciel estampillé
détecteur de fuite que de vendre un programmeur estampillé pisseur de
codes sans bug. Non ?
Oui, il n'y a qu'a voir le succes de Java compare a C++ :)
c'est quand mêne plus facile de vendre un logiciel estampillé détecteur de fuite que de vendre un programmeur estampillé pisseur de codes sans bug. Non ?
Oui, il n'y a qu'a voir le succes de Java compare a C++ :)
