compilateur graphique gratuit avec debugeur ?

Harpo

08/12/2005 à 07:52

Emmanuel Delahaye wrote:

j'écris des tests unitaires et je m'arrange pour
qu'ils puissent servir d'exemples en complément de la doc,

Bon ben voilà, t'as compris.

Cela ne dispense pas de la doc.

Sinon, je pense que le codage est
suffisament auto documenté pour se passer de doc, surtout pour un
programmeur chevronné comme toi...

Sans relever ton ironie, je crois que tu es à coté de la plaque.
Il ne faut pas mêler les niveaux de compréhension d'un logiciel et je ne
pense que ce n'est pas en sachant comment il le fait qu'il faut déduire
ce qu'il fait.
S'il fallait avoir lu le source de toutes les bibliothèques que l'on
utilise pour savoir ce qu'elles font, il ne resterait plus de temps
pour les utiliser.

La seule chose à préciser, et encore, c'est le rôle du paramètre de
fstr_create(). C'est un entier (puissance de 2 de préférence, minimum
1, Attention, avec 0, le comportement est indéfini !) qui indique la
taille initiale de la chaine. (Taille dite 'raisonnable')

C'est une manie de faire des comportements indéfinis alors qu'on a la
possibilité de les définir ? A la lecture de cette fonction, il ne me
semble pas que son comportement soit indéfini dans ce cas.

De toute manière, c'est le genre de paramètre qui devrait être optionnel
( 0 indiquant qu'on veut le défaut ), le défaut étant éventuellement
paramétrable de l'exterieur, le programmeur ne sachant généralement pas
quelles chaînes va traiter le programme et parfois même n'a pas d'ordre
d'idées de leur longueur. La manière d'agrandir pourrait aussi être
parametrable, multiplier la taille par 2 n'est pas toujours la
meilleure stratégie, à partir d'un moment il faut tenir compte de la
taille de la page.

De plus, ce size devrait être arrondi de manière à ce qu'il fasse la
taille d'un long (voire d'une puissance de 2 de cette taille). Allouer
3 puis 6 puis 12 est une mauvaise économie,

Ensuite, lorsque realloc ne marche pas, la fonction renvoie une erreur,
alors que c'est justement l'interêt de passer par une indirection (par
l'intermédiaire de ton this) que de pouvoir refaire un malloc et y
recopier la chaîne, ce qui ne demande pas des prouesses de
programmation.

Et encore, il y a des mises à 0 inutiles de la mémoire allouée.
Il manque les fonctions de copy, de comparaison et toutes les autres
fonctions utiles portant sur des chaînes

Si tu te sens le courage d'écrire une doc, tu es le bienvenu !

Merci, d'ailleurs je m'y emploie déjà. J'y passe le plus clair de mon
temps, c'est très chiant mais écrire une doc est un gain de ressources
à un niveau global, il est préférable qu'une personne passe 2 heures à
écrire une doc plutôt que 100 personnes passent 1 heure de plus à
essayer de comprendre sans doc.

Emmanuel Delahaye wrote:

j'écris des tests unitaires et je m'arrange pour
qu'ils puissent servir d'exemples en complément de la doc,

Bon ben voilà, t'as compris.

Cela ne dispense pas de la doc.

Sinon, je pense que le codage est
suffisament auto documenté pour se passer de doc, surtout pour un
programmeur chevronné comme toi...

Sans relever ton ironie, je crois que tu es à coté de la plaque.
Il ne faut pas mêler les niveaux de compréhension d'un logiciel et je ne
pense que ce n'est pas en sachant comment il le fait qu'il faut déduire
ce qu'il fait.
S'il fallait avoir lu le source de toutes les bibliothèques que l'on
utilise pour savoir ce qu'elles font, il ne resterait plus de temps
pour les utiliser.

La seule chose à préciser, et encore, c'est le rôle du paramètre de
fstr_create(). C'est un entier (puissance de 2 de préférence, minimum
1, Attention, avec 0, le comportement est indéfini !) qui indique la
taille initiale de la chaine. (Taille dite 'raisonnable')

C'est une manie de faire des comportements indéfinis alors qu'on a la
possibilité de les définir ? A la lecture de cette fonction, il ne me
semble pas que son comportement soit indéfini dans ce cas.

De toute manière, c'est le genre de paramètre qui devrait être optionnel
( 0 indiquant qu'on veut le défaut ), le défaut étant éventuellement
paramétrable de l'exterieur, le programmeur ne sachant généralement pas
quelles chaînes va traiter le programme et parfois même n'a pas d'ordre
d'idées de leur longueur. La manière d'agrandir pourrait aussi être
parametrable, multiplier la taille par 2 n'est pas toujours la
meilleure stratégie, à partir d'un moment il faut tenir compte de la
taille de la page.

De plus, ce size devrait être arrondi de manière à ce qu'il fasse la
taille d'un long (voire d'une puissance de 2 de cette taille). Allouer
3 puis 6 puis 12 est une mauvaise économie,

Ensuite, lorsque realloc ne marche pas, la fonction renvoie une erreur,
alors que c'est justement l'interêt de passer par une indirection (par
l'intermédiaire de ton this) que de pouvoir refaire un malloc et y
recopier la chaîne, ce qui ne demande pas des prouesses de
programmation.

Et encore, il y a des mises à 0 inutiles de la mémoire allouée.
Il manque les fonctions de copy, de comparaison et toutes les autres
fonctions utiles portant sur des chaînes

Si tu te sens le courage d'écrire une doc, tu es le bienvenu !

Merci, d'ailleurs je m'y emploie déjà. J'y passe le plus clair de mon
temps, c'est très chiant mais écrire une doc est un gain de ressources
à un niveau global, il est préférable qu'une personne passe 2 heures à
écrire une doc plutôt que 100 personnes passent 1 heure de plus à
essayer de comprendre sans doc.

Vous avez filtré cet utilisateur ! Consultez son message

Emmanuel Delahaye wrote:

j'écris des tests unitaires et je m'arrange pour
qu'ils puissent servir d'exemples en complément de la doc,

Bon ben voilà, t'as compris.

Cela ne dispense pas de la doc.

Sinon, je pense que le codage est
suffisament auto documenté pour se passer de doc, surtout pour un
programmeur chevronné comme toi...

Sans relever ton ironie, je crois que tu es à coté de la plaque.
Il ne faut pas mêler les niveaux de compréhension d'un logiciel et je ne
pense que ce n'est pas en sachant comment il le fait qu'il faut déduire
ce qu'il fait.
S'il fallait avoir lu le source de toutes les bibliothèques que l'on
utilise pour savoir ce qu'elles font, il ne resterait plus de temps
pour les utiliser.

La seule chose à préciser, et encore, c'est le rôle du paramètre de
fstr_create(). C'est un entier (puissance de 2 de préférence, minimum
1, Attention, avec 0, le comportement est indéfini !) qui indique la
taille initiale de la chaine. (Taille dite 'raisonnable')

C'est une manie de faire des comportements indéfinis alors qu'on a la
possibilité de les définir ? A la lecture de cette fonction, il ne me
semble pas que son comportement soit indéfini dans ce cas.

De toute manière, c'est le genre de paramètre qui devrait être optionnel
( 0 indiquant qu'on veut le défaut ), le défaut étant éventuellement
paramétrable de l'exterieur, le programmeur ne sachant généralement pas
quelles chaînes va traiter le programme et parfois même n'a pas d'ordre
d'idées de leur longueur. La manière d'agrandir pourrait aussi être
parametrable, multiplier la taille par 2 n'est pas toujours la
meilleure stratégie, à partir d'un moment il faut tenir compte de la
taille de la page.

De plus, ce size devrait être arrondi de manière à ce qu'il fasse la
taille d'un long (voire d'une puissance de 2 de cette taille). Allouer
3 puis 6 puis 12 est une mauvaise économie,

Ensuite, lorsque realloc ne marche pas, la fonction renvoie une erreur,
alors que c'est justement l'interêt de passer par une indirection (par
l'intermédiaire de ton this) que de pouvoir refaire un malloc et y
recopier la chaîne, ce qui ne demande pas des prouesses de
programmation.

Et encore, il y a des mises à 0 inutiles de la mémoire allouée.
Il manque les fonctions de copy, de comparaison et toutes les autres
fonctions utiles portant sur des chaînes

Si tu te sens le courage d'écrire une doc, tu es le bienvenu !

Merci, d'ailleurs je m'y emploie déjà. J'y passe le plus clair de mon
temps, c'est très chiant mais écrire une doc est un gain de ressources
à un niveau global, il est préférable qu'une personne passe 2 heures à
écrire une doc plutôt que 100 personnes passent 1 heure de plus à
essayer de comprendre sans doc.

Eric Deveaud

08/12/2005 à 09:31

Harpo wrote:

La manière d'agrandir pourrait aussi être parametrable, multiplier la taille
par 2 n'est pas toujours la meilleure stratégie, à partir d'un moment il
faut tenir compte de la taille de la page.

pourrais-tu détailler stp, c'est un problème auquel je suis osuvent confronté

De plus, ce size devrait être arrondi de manière à ce qu'il fasse la
taille d'un long (voire d'une puissance de 2 de cette taille). Allouer
3 puis 6 puis 12 est une mauvaise économie,

en complément à ma question ci-dessus, je veux bien des éclairssissements sur
ce point

Eric

Jean-Marc Bourguet

08/12/2005 à 13:39

Harpo writes:

Merci, d'ailleurs je m'y emploie déjà. J'y passe le plus clair de mon
temps, c'est très chiant mais écrire une doc est un gain de ressources
à un niveau global, il est préférable qu'une personne passe 2 heures à
écrire une doc plutôt que 100 personnes passent 1 heure de plus à
essayer de comprendre sans doc.

L'important, c'est que la doc permet de savoir quelles sont les
proprietes qui sont desirees, celles qui sont le fruit du hasard,
celles qui sont des bugs et seront supprimees des que le responsable
du code s'en rendra compte.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet

08/12/2005 à 13:41

Jean-Marc Bourguet writes:

Harpo writes:

Merci, d'ailleurs je m'y emploie déjà. J'y passe le plus clair de mon
temps, c'est très chiant mais écrire une doc est un gain de ressources
à un niveau global, il est préférable qu'une personne passe 2 heures à
écrire une doc plutôt que 100 personnes passent 1 heure de plus à
essayer de comprendre sans doc.

L'important, c'est que la doc permet de savoir quelles sont les
proprietes qui sont desirees, celles qui sont le fruit du hasard,
celles qui sont des bugs et seront supprimees des que le responsable
du code s'en rendra compte.

Au fait, les tests faits en connaissant l'implementation ne permettent
pas de discerner les deux premiers cas mais on peut esperer que le
troisieme ne s'y trouve pas :-)

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Harpo

08/12/2005 à 20:20

Eric Deveaud wrote:

Harpo wrote:

La manière d'agrandir pourrait aussi être parametrable, multiplier
la taille par 2 n'est pas toujours la meilleure stratégie, à partir
d'un moment il faut tenir compte de la taille de la page.

pourrais-tu détailler stp, c'est un problème auquel je suis osuvent
confronté

Non, car les quelques petites connaissances que j'ai eu dans ce domaine
ne sont plus très fraîches.
Ce n'est pas simple et cela dépend de l'implémentation de malloc() et
aussi du système sous-jacent pour l'allocation des pages.
La page *peut* être considérée comme l'unité d'allocation au process, si
on fait une allocation qui déborde d'une page ne serait-ce que d'un
byte, cela demande une page supplémentaire, ce qui peut coûter des
ressources au niveau du système, mais suivant le système et la manière
dont il est règlé, il peut n'y avoir aucune différence notable entre le
fait d'allouer une page ou 100.
Il est préférable, en tout cas plus simple, de se contenter de tenir
compte de la manière dont marchent les fonctions comme malloc sur les
systèmes sur lesquels on veut faire tourner les programmes, croire que
la connaissance du système sous-jacent va permettre d'optimiser ses
programmes expose à des déconfitures, il est peut-être préférable de se
contenter de quelques règles simples tenant compte du système sur
lequel le programme doit tourner le plus souvent et faire en sorte que
ça marche partout.
Il y a toujours une espèce de marchandage entre la place utilisée, le
temps utilisé, ce qui complique c'est qu'au nivau global de la machine,
c'est lié, on ne peut pas faire varier ces parametres indépendamment et
le profiling d'un programme n'apprend pas grand chose quand au débit
d'une machine. ce n'est pas important sur une machine de bureau qui
passe son temps dans une idle loop et qui ne travaille vraiment que
lorsqu'on clique, c'est plus important pour une machine sur laquelle
sont implantés des serveurs sollicités.

Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est possible.
. ne pas allouer des petit morceaux de mémoire, pour quelque chose comme
1 ligne de commande, allouer 256 bytes, cela permet de faire 1 realloc
tous les 8 jours seulement. pour charger un fichier en mémoire faire un
fstat et arrondir à la taille de page ou 1 multiple de 2 suivant la
taille, mais généralement pour des petits programmes ce n'est même pas
la peine de s'en soucier.

De plus, ce size devrait être arrondi de manière à ce qu'il fasse la
taille d'un long (voire d'une puissance de 2 de cette taille).
Allouer 3 puis 6 puis 12 est une mauvaise économie,

en complément à ma question ci-dessus, je veux bien des
éclairssissements sur ce point

Quand on alloue de la mémoire, l'adresse est alignée, sur le système sur
lequel je suis, 64 bits, soit 2 long.
Malloc utilise aussi de la mémoire pour chaîner la mémoire allouée, je
pense qu'il a besoin de 3 adresses souvent allouées devant la mémoire
fournie.
Allouer 1 byte est ridicule, Si on veut un second faire un realloc !
C'est du délire !
Je ne vois pas de raison d'allouer moins de 4 mots, sinon après 64 etc,
au minimum aligner sur la frontière du plus grand objet, chez moi 8
mais carrément prendre 16 pour les générations futures. Et encore c'est
voir très petit.

Comme tu sembles être sur Debian GNU/Linux :
http://www.delorie.com/gnu/docs/glibc/libc_19.html

Eric Deveaud wrote:

Harpo wrote:

La manière d'agrandir pourrait aussi être parametrable, multiplier
la taille par 2 n'est pas toujours la meilleure stratégie, à partir
d'un moment il faut tenir compte de la taille de la page.

pourrais-tu détailler stp, c'est un problème auquel je suis osuvent
confronté

Non, car les quelques petites connaissances que j'ai eu dans ce domaine
ne sont plus très fraîches.
Ce n'est pas simple et cela dépend de l'implémentation de malloc() et
aussi du système sous-jacent pour l'allocation des pages.
La page *peut* être considérée comme l'unité d'allocation au process, si
on fait une allocation qui déborde d'une page ne serait-ce que d'un
byte, cela demande une page supplémentaire, ce qui peut coûter des
ressources au niveau du système, mais suivant le système et la manière
dont il est règlé, il peut n'y avoir aucune différence notable entre le
fait d'allouer une page ou 100.
Il est préférable, en tout cas plus simple, de se contenter de tenir
compte de la manière dont marchent les fonctions comme malloc sur les
systèmes sur lesquels on veut faire tourner les programmes, croire que
la connaissance du système sous-jacent va permettre d'optimiser ses
programmes expose à des déconfitures, il est peut-être préférable de se
contenter de quelques règles simples tenant compte du système sur
lequel le programme doit tourner le plus souvent et faire en sorte que
ça marche partout.
Il y a toujours une espèce de marchandage entre la place utilisée, le
temps utilisé, ce qui complique c'est qu'au nivau global de la machine,
c'est lié, on ne peut pas faire varier ces parametres indépendamment et
le profiling d'un programme n'apprend pas grand chose quand au débit
d'une machine. ce n'est pas important sur une machine de bureau qui
passe son temps dans une idle loop et qui ne travaille vraiment que
lorsqu'on clique, c'est plus important pour une machine sur laquelle
sont implantés des serveurs sollicités.

Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est possible.
. ne pas allouer des petit morceaux de mémoire, pour quelque chose comme
1 ligne de commande, allouer 256 bytes, cela permet de faire 1 realloc
tous les 8 jours seulement. pour charger un fichier en mémoire faire un
fstat et arrondir à la taille de page ou 1 multiple de 2 suivant la
taille, mais généralement pour des petits programmes ce n'est même pas
la peine de s'en soucier.

De plus, ce size devrait être arrondi de manière à ce qu'il fasse la
taille d'un long (voire d'une puissance de 2 de cette taille).
Allouer 3 puis 6 puis 12 est une mauvaise économie,

en complément à ma question ci-dessus, je veux bien des
éclairssissements sur ce point

Quand on alloue de la mémoire, l'adresse est alignée, sur le système sur
lequel je suis, 64 bits, soit 2 long.
Malloc utilise aussi de la mémoire pour chaîner la mémoire allouée, je
pense qu'il a besoin de 3 adresses souvent allouées devant la mémoire
fournie.
Allouer 1 byte est ridicule, Si on veut un second faire un realloc !
C'est du délire !
Je ne vois pas de raison d'allouer moins de 4 mots, sinon après 64 etc,
au minimum aligner sur la frontière du plus grand objet, chez moi 8
mais carrément prendre 16 pour les générations futures. Et encore c'est
voir très petit.

Comme tu sembles être sur Debian GNU/Linux :
http://www.delorie.com/gnu/docs/glibc/libc_19.html

Vous avez filtré cet utilisateur ! Consultez son message

Eric Deveaud wrote:

Harpo wrote:

La manière d'agrandir pourrait aussi être parametrable, multiplier
la taille par 2 n'est pas toujours la meilleure stratégie, à partir
d'un moment il faut tenir compte de la taille de la page.

pourrais-tu détailler stp, c'est un problème auquel je suis osuvent
confronté

Non, car les quelques petites connaissances que j'ai eu dans ce domaine
ne sont plus très fraîches.
Ce n'est pas simple et cela dépend de l'implémentation de malloc() et
aussi du système sous-jacent pour l'allocation des pages.
La page *peut* être considérée comme l'unité d'allocation au process, si
on fait une allocation qui déborde d'une page ne serait-ce que d'un
byte, cela demande une page supplémentaire, ce qui peut coûter des
ressources au niveau du système, mais suivant le système et la manière
dont il est règlé, il peut n'y avoir aucune différence notable entre le
fait d'allouer une page ou 100.
Il est préférable, en tout cas plus simple, de se contenter de tenir
compte de la manière dont marchent les fonctions comme malloc sur les
systèmes sur lesquels on veut faire tourner les programmes, croire que
la connaissance du système sous-jacent va permettre d'optimiser ses
programmes expose à des déconfitures, il est peut-être préférable de se
contenter de quelques règles simples tenant compte du système sur
lequel le programme doit tourner le plus souvent et faire en sorte que
ça marche partout.
Il y a toujours une espèce de marchandage entre la place utilisée, le
temps utilisé, ce qui complique c'est qu'au nivau global de la machine,
c'est lié, on ne peut pas faire varier ces parametres indépendamment et
le profiling d'un programme n'apprend pas grand chose quand au débit
d'une machine. ce n'est pas important sur une machine de bureau qui
passe son temps dans une idle loop et qui ne travaille vraiment que
lorsqu'on clique, c'est plus important pour une machine sur laquelle
sont implantés des serveurs sollicités.

Les règles simples de bon sens commun que j'utilise sont :
. éviter de faire des malloc(), préférer alloca() quand c'est possible.
. ne pas allouer des petit morceaux de mémoire, pour quelque chose comme
1 ligne de commande, allouer 256 bytes, cela permet de faire 1 realloc
tous les 8 jours seulement. pour charger un fichier en mémoire faire un
fstat et arrondir à la taille de page ou 1 multiple de 2 suivant la
taille, mais généralement pour des petits programmes ce n'est même pas
la peine de s'en soucier.

De plus, ce size devrait être arrondi de manière à ce qu'il fasse la
taille d'un long (voire d'une puissance de 2 de cette taille).
Allouer 3 puis 6 puis 12 est une mauvaise économie,

en complément à ma question ci-dessus, je veux bien des
éclairssissements sur ce point

Quand on alloue de la mémoire, l'adresse est alignée, sur le système sur
lequel je suis, 64 bits, soit 2 long.
Malloc utilise aussi de la mémoire pour chaîner la mémoire allouée, je
pense qu'il a besoin de 3 adresses souvent allouées devant la mémoire
fournie.
Allouer 1 byte est ridicule, Si on veut un second faire un realloc !
C'est du délire !
Je ne vois pas de raison d'allouer moins de 4 mots, sinon après 64 etc,
au minimum aligner sur la frontière du plus grand objet, chez moi 8
mais carrément prendre 16 pour les générations futures. Et encore c'est
voir très petit.

Comme tu sembles être sur Debian GNU/Linux :
http://www.delorie.com/gnu/docs/glibc/libc_19.html

Harpo

08/12/2005 à 20:25

Jean-Marc Bourguet wrote:

L'important, c'est que la doc permet de savoir quelles sont les
proprietes qui sont desirees, celles qui sont le fruit du hasard,
celles qui sont des bugs et seront supprimees des que le responsable
du code s'en rendra compte.

Oui, l'important est de savoir ce que le programme/ la fonction peut
faire et doit faire quand on lui donne ce qu'il faut.
Les docs ont aussi des bugs ou sont silencieuses sur la manière dont on
voudrait utiliser le truc, mais elles doivent au moins permettre de se
servir du logiciel dans ses fonctionalités simples.

Harpo

08/12/2005 à 20:27

Jean-Marc Bourguet wrote:

L'important, c'est que la doc permet de savoir quelles sont les
proprietes qui sont desirees, celles qui sont le fruit du hasard,
celles qui sont des bugs et seront supprimees des que le responsable
du code s'en rendra compte.

Au fait, les tests faits en connaissant l'implementation ne permettent
pas de discerner les deux premiers cas mais on peut esperer que le
troisieme ne s'y trouve pas :-)

Si tu savais combien il est difficile de faire des test suite qui
évitent de dévoiler des bugs !

Jean-Marc Desperrier

08/12/2005 à 21:53

Harpo wrote:

. éviter de faire des malloc(), préférer alloca() quand c'est possible.

Alloca est-il suffisament portable pour ne pas poser de problème très
rapidement ?

http://lists.gnu.org/archive/html/bug-cvs/2004-04/msg00199.html
Linux, FreeBSD, NetBSD discourage it's use and Linux
man page explains reasons better than others.

http://www.die.net/doc/linux/man/man3/alloca.3.html
The fact that the code is inlined, means that it is impossible
to take the address of this function, or to change its behaviour
by linking with a different library.
=> Et donc de debugguer finement tout problème mémoire

The inlined code often consists of a single instruction
adjusting the stack pointer, and does not check for stack
overflow.

En fait en regardant des référence sous windows pour alloca, j'ai vu une
référence A2W et je connais le bug du A2W qui plante quand on veut
allouer 1 Mo.

Hum, en fait ceci n'est que la conséquence du paramètre par défaut que
l'on peut agrandir à la compilation.

Harpo

08/12/2005 à 23:46

Jean-Marc Desperrier wrote:

Harpo wrote:
. éviter de faire des malloc(), préférer alloca() quand c'est
possible.

Alloca est-il suffisament portable pour ne pas poser de problème très
rapidement ?

http://lists.gnu.org/archive/html/bug-cvs/2004-04/msg00199.html
Linux, FreeBSD, NetBSD discourage it's use and Linux
man page explains reasons better than others.

http://www.die.net/doc/linux/man/man3/alloca.3.html
The fact that the code is inlined, means that it is impossible
to take the address of this function, or to change its behaviour
by linking with a different library.
=> Et donc de debugguer finement tout problème mémoire

The inlined code often consists of a single instruction
adjusting the stack pointer, and does not check for stack
overflow.

L'important est 'a single instruction'.
Tu crois que lorsque tu dépenses quelques milliers d'instructions pour
un malloc() de la mémoire t'est vraiment attribuée ? C'est loin d'être
nécessaire.
Sur un GNU/Linux, fait 'cat /proc/sys/vm/overcommit_memory', si tu es
sur une machine de bureau c'est peut-être 0, sur un serveur sans doute
1 si l'ingénieur système n'est pas trop timoré. l'allocation est
souvent délayée (uh! retardée) jusqu'à la première exception pour
l'accès à la page.
Les programmes sont fait pour se planter, les machines pour assurer un
débit.
Même l'utilisation demesurée du stack simplement par l'appel de fonction
se termine souvent par un signal 11, et quand bien même on voit le
message 'stack overflow', ça fait une belle jambe.
Personnellement, je n'ai dépassé inintentionnellement la taille du stack
qu'en phase de premier test d'une fonction récursive dans laquelle
j'avais malencontreusement mal codé le test d'arrêt, alors allouer 1Kb
dans le stack, quelle plaisanterie lorsqu'on est dans une fonction qui
n'en appelle pas d'autres.
L'idée que 'son' programme ne va pas se planter parce qu'on l'a bien
écrit, qu'on l'a bien testé, bien packagé etc. ne peut naitre que dans
l'esprit d'un programmeur. je fais planter n'importe quel programme en
débranchant l'alim.
Qu'un programme se plante n'arrive pas au niveau de l'anecdote, le
problème est : comment il redemarre ?

Jean-Marc Desperrier wrote:

Harpo wrote:

. éviter de faire des malloc(), préférer alloca() quand c'est
possible.

Alloca est-il suffisament portable pour ne pas poser de problème très
rapidement ?

http://lists.gnu.org/archive/html/bug-cvs/2004-04/msg00199.html
Linux, FreeBSD, NetBSD discourage it's use and Linux
man page explains reasons better than others.

http://www.die.net/doc/linux/man/man3/alloca.3.html
The fact that the code is inlined, means that it is impossible
to take the address of this function, or to change its behaviour
by linking with a different library.
=> Et donc de debugguer finement tout problème mémoire

The inlined code often consists of a single instruction
adjusting the stack pointer, and does not check for stack
overflow.

L'important est 'a single instruction'.
Tu crois que lorsque tu dépenses quelques milliers d'instructions pour
un malloc() de la mémoire t'est vraiment attribuée ? C'est loin d'être
nécessaire.
Sur un GNU/Linux, fait 'cat /proc/sys/vm/overcommit_memory', si tu es
sur une machine de bureau c'est peut-être 0, sur un serveur sans doute
1 si l'ingénieur système n'est pas trop timoré. l'allocation est
souvent délayée (uh! retardée) jusqu'à la première exception pour
l'accès à la page.
Les programmes sont fait pour se planter, les machines pour assurer un
débit.
Même l'utilisation demesurée du stack simplement par l'appel de fonction
se termine souvent par un signal 11, et quand bien même on voit le
message 'stack overflow', ça fait une belle jambe.
Personnellement, je n'ai dépassé inintentionnellement la taille du stack
qu'en phase de premier test d'une fonction récursive dans laquelle
j'avais malencontreusement mal codé le test d'arrêt, alors allouer 1Kb
dans le stack, quelle plaisanterie lorsqu'on est dans une fonction qui
n'en appelle pas d'autres.
L'idée que 'son' programme ne va pas se planter parce qu'on l'a bien
écrit, qu'on l'a bien testé, bien packagé etc. ne peut naitre que dans
l'esprit d'un programmeur. je fais planter n'importe quel programme en
débranchant l'alim.
Qu'un programme se plante n'arrive pas au niveau de l'anecdote, le
problème est : comment il redemarre ?

Vous avez filtré cet utilisateur ! Consultez son message

Jean-Marc Desperrier wrote:

Harpo wrote:
. éviter de faire des malloc(), préférer alloca() quand c'est
possible.

Alloca est-il suffisament portable pour ne pas poser de problème très
rapidement ?

http://lists.gnu.org/archive/html/bug-cvs/2004-04/msg00199.html
Linux, FreeBSD, NetBSD discourage it's use and Linux
man page explains reasons better than others.

http://www.die.net/doc/linux/man/man3/alloca.3.html
The fact that the code is inlined, means that it is impossible
to take the address of this function, or to change its behaviour
by linking with a different library.
=> Et donc de debugguer finement tout problème mémoire

The inlined code often consists of a single instruction
adjusting the stack pointer, and does not check for stack
overflow.

L'important est 'a single instruction'.
Tu crois que lorsque tu dépenses quelques milliers d'instructions pour
un malloc() de la mémoire t'est vraiment attribuée ? C'est loin d'être
nécessaire.
Sur un GNU/Linux, fait 'cat /proc/sys/vm/overcommit_memory', si tu es
sur une machine de bureau c'est peut-être 0, sur un serveur sans doute
1 si l'ingénieur système n'est pas trop timoré. l'allocation est
souvent délayée (uh! retardée) jusqu'à la première exception pour
l'accès à la page.
Les programmes sont fait pour se planter, les machines pour assurer un
débit.
Même l'utilisation demesurée du stack simplement par l'appel de fonction
se termine souvent par un signal 11, et quand bien même on voit le
message 'stack overflow', ça fait une belle jambe.
Personnellement, je n'ai dépassé inintentionnellement la taille du stack
qu'en phase de premier test d'une fonction récursive dans laquelle
j'avais malencontreusement mal codé le test d'arrêt, alors allouer 1Kb
dans le stack, quelle plaisanterie lorsqu'on est dans une fonction qui
n'en appelle pas d'autres.
L'idée que 'son' programme ne va pas se planter parce qu'on l'a bien
écrit, qu'on l'a bien testé, bien packagé etc. ne peut naitre que dans
l'esprit d'un programmeur. je fais planter n'importe quel programme en
débranchant l'alim.
Qu'un programme se plante n'arrive pas au niveau de l'anecdote, le
problème est : comment il redemarre ?

Charlie Gordon

09/12/2005 à 01:36

"Harpo" wrote in message
news:4397267f$0$21302$

Emmanuel Delahaye wrote:

Les fonctions str* sont à utiliser avec parcimonie et à bon escient,
c'est à dire quasiment jamais.

N'importe quoi...

Je maintiens et je double la mise.

Vrai pour strncpy, strncat et strtok ;-)

--
Chqrlie.

compilateur graphique gratuit avec debugeur ?

10 réponses

Veuillez sélectionner un problème