En me balladant tranquillement dans les sources de la libc de FreeBSD, j'ai rencontré un petit bout de code effrayant au détour de malloc.c :
/* If it's empty, make a page more of that size chunks */ if (!page_dir[j] && !malloc_make_chunks(j)) return 0;
En quoi est-il effrayant ?
Le seul reproche esthétique qu'on puisse lui faire c'est de comparer page_dir[] à zéro plutôt que NULL (et pareil pour la valeur renvoyée).
Si malloc_make_chunks() renvoie zéro, il n'y a plus de mémoire, de toutes façons...
Cyrille Szymanski
On 2004-04-21, Miod Vallat wrote:
En me balladant tranquillement dans les sources de la libc de FreeBSD, j'ai rencontré un petit bout de code effrayant au détour de malloc.c :
/* If it's empty, make a page more of that size chunks */ if (!page_dir[j] && !malloc_make_chunks(j)) return 0;
En quoi est-il effrayant ?
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars veut dire, appelle malloc_make_chunks() que si page_dir[] est égal à 0 (ou NULL si tu veux).
Je vois bien que ça fonctionne, et c'est peut-être même écrit dans la norme du C que ça doit être interprété comme ça. Mais pour la clarté du code c'est pas top.
Ou alors c'est que je suis pas habitué.
-- cns
On 2004-04-21, Miod Vallat <miod@online.fr> wrote:
En me balladant tranquillement dans les sources de la libc de
FreeBSD, j'ai rencontré un petit bout de code effrayant au
détour de malloc.c :
/* If it's empty, make a page more of that size chunks */
if (!page_dir[j] && !malloc_make_chunks(j))
return 0;
En quoi est-il effrayant ?
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars
veut dire, appelle malloc_make_chunks() que si page_dir[] est
égal à 0 (ou NULL si tu veux).
Je vois bien que ça fonctionne, et c'est peut-être même écrit
dans la norme du C que ça doit être interprété comme ça. Mais
pour la clarté du code c'est pas top.
En me balladant tranquillement dans les sources de la libc de FreeBSD, j'ai rencontré un petit bout de code effrayant au détour de malloc.c :
/* If it's empty, make a page more of that size chunks */ if (!page_dir[j] && !malloc_make_chunks(j)) return 0;
En quoi est-il effrayant ?
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars veut dire, appelle malloc_make_chunks() que si page_dir[] est égal à 0 (ou NULL si tu veux).
Je vois bien que ça fonctionne, et c'est peut-être même écrit dans la norme du C que ça doit être interprété comme ça. Mais pour la clarté du code c'est pas top.
Ou alors c'est que je suis pas habitué.
-- cns
Vincent
Cyrille Szymanski dixit :
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars veut dire, appelle malloc_make_chunks() que si page_dir[] est égal à 0 (ou NULL si tu veux). Je vois bien que ça fonctionne, et c'est peut-être même écrit dans la norme du C que ça doit être interprété comme ça. Mais pour la clarté du code c'est pas top.
Ben c'est même dans l'édition originale du K&R ce genre de choses. Comme quoi, ça date pas d'hier...
Vincent
Cyrille Szymanski <cns2@cns.invalid> dixit :
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars
veut dire, appelle malloc_make_chunks() que si page_dir[] est
égal à 0 (ou NULL si tu veux).
Je vois bien que ça fonctionne, et c'est peut-être même écrit
dans la norme du C que ça doit être interprété comme ça. Mais
pour la clarté du code c'est pas top.
Ben c'est même dans l'édition originale du K&R ce genre de choses. Comme
quoi, ça date pas d'hier...
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars veut dire, appelle malloc_make_chunks() que si page_dir[] est égal à 0 (ou NULL si tu veux). Je vois bien que ça fonctionne, et c'est peut-être même écrit dans la norme du C que ça doit être interprété comme ça. Mais pour la clarté du code c'est pas top.
Ben c'est même dans l'édition originale du K&R ce genre de choses. Comme quoi, ça date pas d'hier...
Vincent
Marwan Burelle
On 21 Apr 2004 12:59:47 GMT Vincent wrote:
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars veut dire, appelle malloc_make_chunks() que si page_dir[] est égal à 0 (ou NULL si tu veux). Je vois bien que ça fonctionne, et c'est peut-être même écrit dans la norme du C que ça doit être interprété comme ça. Mais pour la clarté du code c'est pas top.
Ben c'est même dans l'édition originale du K&R ce genre de choses. Comme quoi, ça date pas d'hier...
Effectivement, && est un "et" feignant, c'est sa sémantique, donc il n'y a pas de problème à l'utiliser pour ce genre de chose.
Maintenant question lisibilité ... éventuellement, on peut critiquer, mais bien des fois, si lisibilité impose un code moins compact et donc probablement moins "efficace", mieux vaut laisser tomber le C ;)
Mais vous, comment l'écrireriez vous ?
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On 21 Apr 2004 12:59:47 GMT
Vincent <21.101@free.fr> wrote:
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars
veut dire, appelle malloc_make_chunks() que si page_dir[] est
égal à 0 (ou NULL si tu veux).
Je vois bien que ça fonctionne, et c'est peut-être même écrit
dans la norme du C que ça doit être interprété comme ça. Mais
pour la clarté du code c'est pas top.
Ben c'est même dans l'édition originale du K&R ce genre de choses.
Comme quoi, ça date pas d'hier...
Effectivement, && est un "et" feignant, c'est sa sémantique, donc il n'y
a pas de problème à l'utiliser pour ce genre de chose.
Maintenant question lisibilité ... éventuellement, on peut critiquer,
mais bien des fois, si lisibilité impose un code moins compact et donc
probablement moins "efficace", mieux vaut laisser tomber le C ;)
Mais vous, comment l'écrireriez vous ?
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
En écrivant "!page_dir[j] && !malloc_make_chunks(j)", le gars veut dire, appelle malloc_make_chunks() que si page_dir[] est égal à 0 (ou NULL si tu veux). Je vois bien que ça fonctionne, et c'est peut-être même écrit dans la norme du C que ça doit être interprété comme ça. Mais pour la clarté du code c'est pas top.
Ben c'est même dans l'édition originale du K&R ce genre de choses. Comme quoi, ça date pas d'hier...
Effectivement, && est un "et" feignant, c'est sa sémantique, donc il n'y a pas de problème à l'utiliser pour ce genre de chose.
Maintenant question lisibilité ... éventuellement, on peut critiquer, mais bien des fois, si lisibilité impose un code moins compact et donc probablement moins "efficace", mieux vaut laisser tomber le C ;)
Mais vous, comment l'écrireriez vous ?
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Cyrille Szymanski
On 2004-04-21, Marwan Burelle wrote:
On 21 Apr 2004 12:59:47 GMT Vincent wrote:
Ben c'est même dans l'édition originale du K&R ce genre de choses. Comme quoi, ça date pas d'hier...
Effectivement, && est un "et" feignant, c'est sa sémantique, donc il n'y a pas de problème à l'utiliser pour ce genre de chose.
Ok, c'est sûrement une question d'habitude.
Maintenant question lisibilité ... éventuellement, on peut critiquer, mais bien des fois, si lisibilité impose un code moins compact et donc probablement moins "efficace", mieux vaut laisser tomber le C ;)
Mais vous, comment l'écrireriez vous ?
Bonne question.
/* If it's empty, make a page more of that size chunks */ if( page_dir[j]==NULL ) { if( malloc_free_chunks(j)==NULL ) return 0; }
Je pense qu'au niveau du code généré c'est équivalent. Mais comme on dit, les goûts et les couleurs ne se discutent pas, tant que ça fonctionne...
-- cns
On 2004-04-21, Marwan Burelle <burelle@lri.fr> wrote:
On 21 Apr 2004 12:59:47 GMT
Vincent <21.101@free.fr> wrote:
Ben c'est même dans l'édition originale du K&R ce genre de choses.
Comme quoi, ça date pas d'hier...
Effectivement, && est un "et" feignant, c'est sa sémantique, donc il n'y
a pas de problème à l'utiliser pour ce genre de chose.
Ok, c'est sûrement une question d'habitude.
Maintenant question lisibilité ... éventuellement, on peut critiquer,
mais bien des fois, si lisibilité impose un code moins compact et donc
probablement moins "efficace", mieux vaut laisser tomber le C ;)
Mais vous, comment l'écrireriez vous ?
Bonne question.
/* If it's empty, make a page more of that size chunks */
if( page_dir[j]==NULL ) {
if( malloc_free_chunks(j)==NULL )
return 0;
}
Je pense qu'au niveau du code généré c'est équivalent.
Mais comme on dit, les goûts et les couleurs ne se discutent pas,
tant que ça fonctionne...
Ben c'est même dans l'édition originale du K&R ce genre de choses. Comme quoi, ça date pas d'hier...
Effectivement, && est un "et" feignant, c'est sa sémantique, donc il n'y a pas de problème à l'utiliser pour ce genre de chose.
Ok, c'est sûrement une question d'habitude.
Maintenant question lisibilité ... éventuellement, on peut critiquer, mais bien des fois, si lisibilité impose un code moins compact et donc probablement moins "efficace", mieux vaut laisser tomber le C ;)
Mais vous, comment l'écrireriez vous ?
Bonne question.
/* If it's empty, make a page more of that size chunks */ if( page_dir[j]==NULL ) { if( malloc_free_chunks(j)==NULL ) return 0; }
Je pense qu'au niveau du code généré c'est équivalent. Mais comme on dit, les goûts et les couleurs ne se discutent pas, tant que ça fonctionne...
-- cns
manu
Cyrille Szymanski wrote:
Je vois bien que ça fonctionne, et c'est peut-être même écrit dans la norme du C que ça doit être interprété comme ça. Mais pour la clarté du code c'est pas top.
Ou alors c'est que je suis pas habitué.
T'es pas habitué :)
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Cyrille Szymanski <cns2@cns.invalid> wrote:
Je vois bien que ça fonctionne, et c'est peut-être même écrit
dans la norme du C que ça doit être interprété comme ça. Mais
pour la clarté du code c'est pas top.
Ou alors c'est que je suis pas habitué.
T'es pas habitué :)
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Je vois bien que ça fonctionne, et c'est peut-être même écrit dans la norme du C que ça doit être interprété comme ça. Mais pour la clarté du code c'est pas top.
Ou alors c'est que je suis pas habitué.
T'es pas habitué :)
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Vincent
Marwan Burelle dixit :
Maintenant question lisibilité ... éventuellement, on peut critiquer, mais bien des fois, si lisibilité impose un code moins compact et donc probablement moins "efficace", mieux vaut laisser tomber le C ;) Mais vous, comment l'écrireriez vous ?
Avec des trigraphes ? :)
Vincent
Marwan Burelle <burelle@lri.fr> dixit :
Maintenant question lisibilité ... éventuellement, on peut critiquer,
mais bien des fois, si lisibilité impose un code moins compact et donc
probablement moins "efficace", mieux vaut laisser tomber le C ;)
Mais vous, comment l'écrireriez vous ?
Maintenant question lisibilité ... éventuellement, on peut critiquer, mais bien des fois, si lisibilité impose un code moins compact et donc probablement moins "efficace", mieux vaut laisser tomber le C ;) Mais vous, comment l'écrireriez vous ?
Avec des trigraphes ? :)
Vincent
Miod Vallat
/* If it's empty, make a page more of that size chunks */ if( page_dir[j]==NULL ) { if( malloc_free_chunks(j)==NULL ) return 0; }
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur lors d'une evolution de code.
Non, car c'est un couple d'opération qui a une sémantique symbolique.
La logique ici, c'est «j'ai besoin d'un bloc». Et l'existence d'un bloc s'exprime sous la forme «j'en ai déjà un, ou je parviens à en créer un», qui correspond au code initial.
Le fait que le test && soit une évaluation booléenne paresseuse est une «feature», mais justement parce que c'est la façon humaine naturelle de procéder.
En fait, il y a un bug mineur dans ce code : tous les chemins de code conduisant à renvoyer NULL ne fixent pas errno à ENOMEM.
Il y en a toujours pour penser que coder de facon illisible (donc comme un goret) ca fait "31337" ("elite" en langage elite de goret). Mais bon si ca leur fait plaisir on va pas gacher leur bonheur :)
Ah, c'est sûr que, en Ruby, on ne laisse pas au programmeur la responsabilité de gérer la mémoire, ce serait trop dangereux.
/* If it's empty, make a page more of that size chunks */
if( page_dir[j]==NULL ) {
if( malloc_free_chunks(j)==NULL )
return 0;
}
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur lors
d'une evolution de code.
Non, car c'est un couple d'opération qui a une sémantique symbolique.
La logique ici, c'est «j'ai besoin d'un bloc». Et l'existence d'un bloc
s'exprime sous la forme «j'en ai déjà un, ou je parviens à en créer un»,
qui correspond au code initial.
Le fait que le test && soit une évaluation booléenne paresseuse est une
«feature», mais justement parce que c'est la façon humaine naturelle de
procéder.
En fait, il y a un bug mineur dans ce code : tous les chemins de code
conduisant à renvoyer NULL ne fixent pas errno à ENOMEM.
Il y en a toujours pour penser que coder de facon illisible (donc
comme un goret) ca fait "31337" ("elite" en langage elite de goret).
Mais bon si ca leur fait plaisir on va pas gacher leur bonheur :)
Ah, c'est sûr que, en Ruby, on ne laisse pas au programmeur la
responsabilité de gérer la mémoire, ce serait trop dangereux.
/* If it's empty, make a page more of that size chunks */ if( page_dir[j]==NULL ) { if( malloc_free_chunks(j)==NULL ) return 0; }
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur lors d'une evolution de code.
Non, car c'est un couple d'opération qui a une sémantique symbolique.
La logique ici, c'est «j'ai besoin d'un bloc». Et l'existence d'un bloc s'exprime sous la forme «j'en ai déjà un, ou je parviens à en créer un», qui correspond au code initial.
Le fait que le test && soit une évaluation booléenne paresseuse est une «feature», mais justement parce que c'est la façon humaine naturelle de procéder.
En fait, il y a un bug mineur dans ce code : tous les chemins de code conduisant à renvoyer NULL ne fixent pas errno à ENOMEM.
Il y en a toujours pour penser que coder de facon illisible (donc comme un goret) ca fait "31337" ("elite" en langage elite de goret). Mais bon si ca leur fait plaisir on va pas gacher leur bonheur :)
Ah, c'est sûr que, en Ruby, on ne laisse pas au programmeur la responsabilité de gérer la mémoire, ce serait trop dangereux.
mips
On 21 Apr 2004 13:32:24 GMT Cyrille Szymanski wrote:
Mais vous, comment l'écrireriez vous ?
Bonne question.
/* If it's empty, make a page more of that size chunks */ if( page_dir[j]==NULL ) { if( malloc_free_chunks(j)==NULL ) return 0; }
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur lors d'une evolution de code.
Je pense qu'au niveau du code généré c'est équivalent.
Je pense de meme.
Mais comme on dit, les goûts et les couleurs ne se discutent pas, tant que ça fonctionne...
Il y en a toujours pour penser que coder de facon illisible (donc comme un goret) ca fait "31337" ("elite" en langage elite de goret). Mais bon si ca leur fait plaisir on va pas gacher leur bonheur :)
mips
On 21 Apr 2004 13:32:24 GMT
Cyrille Szymanski <cns2@cns.invalid> wrote:
Mais vous, comment l'écrireriez vous ?
Bonne question.
/* If it's empty, make a page more of that size chunks */
if( page_dir[j]==NULL ) {
if( malloc_free_chunks(j)==NULL )
return 0;
}
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur lors
d'une evolution de code.
Je pense qu'au niveau du code généré c'est équivalent.
Je pense de meme.
Mais comme on dit, les goûts et les couleurs ne se discutent pas,
tant que ça fonctionne...
Il y en a toujours pour penser que coder de facon illisible (donc
comme un goret) ca fait "31337" ("elite" en langage elite de goret).
Mais bon si ca leur fait plaisir on va pas gacher leur bonheur :)
On 21 Apr 2004 13:32:24 GMT Cyrille Szymanski wrote:
Mais vous, comment l'écrireriez vous ?
Bonne question.
/* If it's empty, make a page more of that size chunks */ if( page_dir[j]==NULL ) { if( malloc_free_chunks(j)==NULL ) return 0; }
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur lors d'une evolution de code.
Je pense qu'au niveau du code généré c'est équivalent.
Je pense de meme.
Mais comme on dit, les goûts et les couleurs ne se discutent pas, tant que ça fonctionne...
Il y en a toujours pour penser que coder de facon illisible (donc comme un goret) ca fait "31337" ("elite" en langage elite de goret). Mais bon si ca leur fait plaisir on va pas gacher leur bonheur :)
mips
Miod Vallat
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire quelque chose soi-meme quand le language peut le faire de facon transparente. Et en plus ca simplifie le code, que demande le peuple ? (a part le
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire quelque
chose soi-meme quand le language peut le faire de facon transparente.
Et en plus ca simplifie le code, que demande le peuple ? (a part le
Mais ça ne simplifie pas le code, puisqu'il devient plus gros,
verticalement...
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire quelque chose soi-meme quand le language peut le faire de facon transparente. Et en plus ca simplifie le code, que demande le peuple ? (a part le
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
