Le samedi 29 septembre 2012 à 15:57:49, François Boisson a écrit : > Le Sat, 29 Sep 2012 15:22:34 +0200 > > Erwan David <er...@rail.eu.org> a écrit: > > les résultats successifs de malloc n'ont aucune raison > > d'être contigus. Pour agrandir une zone on le fait plutôt > > avec realloc, mais ça peut aussi déplacer complètement la > > zone. > > J'étais en train de me pencher sur ça et me doutais d'un truc > de ce genre... Le déplacement via realloc semble transparent > (pas clair sur la doc), mais le problème est que visiblement > ça fait une extension «par le haut» ce qui est ennuyeux, > visiblement dans le source de camllight, «heap_start» est > une constante à ne pas toucher. Il y a une fonction > étendant la mémoire à «sommet constant»?
À mon avis, c’est un gros bogue de camllight de se reposer sur un comportement non spécifié et dépendant d’une mise en œuvre particulière. 1. malloc n’a, comme l’a dit Erwan, aucune raison d’allouer des blocs côte à côte ; 2. realloc n’a pas d’intérêt à réallouer au même endroit, d’une part parce que, justement, l’intérêt de realloc est de déplacer l’ancien bloc de façon transparente, et, d’autre part, parce que ça me ferait bien chier qu’un programme plante par manque de mémoire parce que la première allocation a été trop petite et placée dans un petit trou non extensible (ou qu’une « meilleure » place ne se soit libérée qu’après) ; 3. une fonction intermédiaire « à sommet constant » ne ferait qu’encourager les programmeurs à faire ce que semble faire camllight. Quand on se fait un tas, les objets que l’on met dedans doivent être placés _relativement_ au début du tas, en clair, on les place par des offset relatifs à heap_start, laquelle valeur doit être dans une _variable_ qui est utilisée _à chaque fois_ pour retrouver l’adresse complète de l’objet. (Et ça fonctionne que ce soit heap_start ou head_end et que l’on y place les objets en « montant » les offsets ou en les « descendant ».) > Merci de la réponse en tout cas. > > François Boisson > PS: Désolé du doublon, je ne comprends pas ce qui c'est pasé > d'autant plus que les deux messages (identoiques) ont été > envoyés à 14s d'écart, sous sylpheed, cela signifie aller le > rechercher pour le réenvoyer aussi sec ce que je n'ai pas > fait... Euh, d’après les en-têtes date, il y a 30 min et 8 s entre les deux… (c. 30 min → délai d’un spool ?) -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201209291751.47105.sylvain.l.sauv...@free.fr
