J'ai un pointeur sur un tableau à deux dimensions.
int ** tab;
ce pointeur est initialisé dans une librairie, à laquelle je n'ai pas
accès. Puis-je savoir par un quelconque moyen quelle est la taille du
tableau à deux dimensions ?
1ère méthode : compiler en mode débug et déduire la taille du tableau
du fait que de chaque coté se trouve des bits de guarde pour
éventuellement vérifier les débordements d'indice. -> trés dépendant
de l'archi.
2ième méthode : avec un tableau int tab[10],
sizeof(tab)/sizeof(tab[0]) me donne la taille du tableau. N'y a-t-il
pas moyen d'étendre cela ? (même si les tableau et les pointeurs ne
sont pas de même type...)
3ième méthode : je rêve complètement, ce n'est pas possible ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Aris
Bonjour,
J'ai un pointeur sur un tableau à deux dimensions.
int ** tab;
3ième méthode : je rêve complètement, ce n'est pas possible ?
C'est la bonne réponse. C'est uniquement possible si votre librairie permet de récuperer cette information via un autre appel.
la méthode 1 marche pas parce que pratiquement aucune librairie C n'inclut de canaries. La 2eme marche pas parce que sizeof() fait partie du compilateur et la norme ne dit absolument rien sur la taille d'une zone pointée (cette information n'existe pas)
reste donc qu'à déduire de manière logique le nombre d'elements qui sont censés arriver dans le tableau. si vous n'avez pas cette information c'est que la librairie est mal foutue ou que vous ne l'utilisez pas comme il faut
Bonjour,
J'ai un pointeur sur un tableau à deux dimensions.
int ** tab;
3ième méthode : je rêve complètement, ce n'est pas possible ?
C'est la bonne réponse. C'est uniquement possible si votre librairie
permet de récuperer cette information via un autre appel.
la méthode 1 marche pas parce que pratiquement aucune librairie C
n'inclut de canaries. La 2eme marche pas parce que sizeof() fait partie
du compilateur et la norme ne dit absolument rien sur la taille d'une
zone pointée (cette information n'existe pas)
reste donc qu'à déduire de manière logique le nombre d'elements qui sont
censés arriver dans le tableau.
si vous n'avez pas cette information c'est que la librairie est mal
foutue ou que vous ne l'utilisez pas comme il faut
J'ai un pointeur sur un tableau à deux dimensions.
int ** tab;
3ième méthode : je rêve complètement, ce n'est pas possible ?
C'est la bonne réponse. C'est uniquement possible si votre librairie permet de récuperer cette information via un autre appel.
la méthode 1 marche pas parce que pratiquement aucune librairie C n'inclut de canaries. La 2eme marche pas parce que sizeof() fait partie du compilateur et la norme ne dit absolument rien sur la taille d'une zone pointée (cette information n'existe pas)
reste donc qu'à déduire de manière logique le nombre d'elements qui sont censés arriver dans le tableau. si vous n'avez pas cette information c'est que la librairie est mal foutue ou que vous ne l'utilisez pas comme il faut
Antoine Leca
En news:fdvnte$vs9$, AG va escriure:
J'ai un pointeur sur un tableau à deux dimensions.
int ** tab;
ce pointeur est initialisé dans une librairie, à laquelle je n'ai pas accès. Puis-je savoir par un quelconque moyen quelle est la taille du tableau à deux dimensions ?
[La taille totale, pas la taille de la dimension intermédiaire, j'espère.]
C'est de la bidouille, mais la réponse est oui.
Pour pouvoir effectuer l'opération free(), sans que l'on dise à free quelle est la taille du bloc précédemment alloué, il faut un peu de /magie/. Cette magie est créee par malloc(). La forme exact de la magie dépend de l'implémentation de malloc() utilisée, mais le détail est en général accessible à travers de fonctions et structures supplémentaires, souvent documentées dans l'entête (non standard évidemment) <malloc.h>.
1ère méthode : compiler en mode débug et déduire la taille du tableau du fait que de chaque coté se trouve des bits de guarde pour éventuellement vérifier les débordements d'indice. -> trés dépendant de l'archi.
Un truc plus simple qui marche bien est de lier ta bibliothèque avec ta propre version de malloc(), et dans l'implémentation de celle-ci faire tous les petits calculs que tu veux, par exemple enregistrer la taille des blocs alloués, les imprimer au passage, les garder dans une liste chaînée pour vérifier qu'il n'y a pas de blocs qui restent alloués sans appel ultérieur à free() etc. Évidemment, il faut _aussi_ que ta propre version de malloc() fournisse l'allocation dynamique :-)
Ce truc (généralement baptisé « debugging malloc library ») a été souvent utilisé, donc il y a pas mal de choses de ce genre qui traînent sur internet. Il faut juste choisir une version qui soit liable à ta bibliothèque (et là, cela dépend complètement du format de celle-ci, statique ou partagée, dynamique ou pas, etc.)
Cela ne marche pas (pas plus que le truc ci-dessus) si la bibliothèque utilise un allocateur intermédiaire, par exemple (c'est surtout le cas pour les machins « orientés objet ») alloue plein de petits morceaux à partir d'un gros bout qu'elle pique une seule fois au système. Vu de l'extérieur, seul le gros bout passe par la mécanique malloc()/free(), les petits morceaux sont gérés entièrement à l'intérieur de la bibliothèque, donc inaccessibles.
2ième méthode : avec un tableau int tab[10], sizeof(tab)/sizeof(tab[0]) me donne la taille du tableau.
Mmm, non, pas vraiment. L'écriture sizeof tab/sizeof tab[0] est un "truc", pas une fonctionnalité ; la fonctionnalité, c'est sizeof, à savoir une primitive du compilateur qui donne la taille d'un objet ; et le compilateur le déduit du type que tu lui as indiqué juste au-dessus, ici « tableaux de 10 entiers » (resp. « entier »).
Pour pouvoir appliquer cette logique à ton cas, il faut auparavant que tu explicites au compilateur... quel est le type du tableau, autrement dit lui dire la taille du tableau. Comme c'est la donnée que tu cherches, on se mord la queue.
Antoine
En news:fdvnte$vs9$1@news.rd.francetelecom.fr, AG va escriure:
J'ai un pointeur sur un tableau à deux dimensions.
int ** tab;
ce pointeur est initialisé dans une librairie, à laquelle je n'ai pas
accès. Puis-je savoir par un quelconque moyen quelle est la taille du
tableau à deux dimensions ?
[La taille totale, pas la taille de la dimension intermédiaire, j'espère.]
C'est de la bidouille, mais la réponse est oui.
Pour pouvoir effectuer l'opération free(), sans que l'on dise à free quelle
est la taille du bloc précédemment alloué, il faut un peu de /magie/. Cette
magie est créee par malloc(). La forme exact de la magie dépend de
l'implémentation de malloc() utilisée, mais le détail est en général
accessible à travers de fonctions et structures supplémentaires, souvent
documentées dans l'entête (non standard évidemment) <malloc.h>.
1ère méthode : compiler en mode débug et déduire la taille du tableau
du fait que de chaque coté se trouve des bits de guarde pour
éventuellement vérifier les débordements d'indice. -> trés dépendant
de l'archi.
Un truc plus simple qui marche bien est de lier ta bibliothèque avec ta
propre version de malloc(), et dans l'implémentation de celle-ci faire tous
les petits calculs que tu veux, par exemple enregistrer la taille des blocs
alloués, les imprimer au passage, les garder dans une liste chaînée pour
vérifier qu'il n'y a pas de blocs qui restent alloués sans appel ultérieur à
free() etc. Évidemment, il faut _aussi_ que ta propre version de malloc()
fournisse l'allocation dynamique :-)
Ce truc (généralement baptisé « debugging malloc library ») a été souvent
utilisé, donc il y a pas mal de choses de ce genre qui traînent sur
internet. Il faut juste choisir une version qui soit liable à ta
bibliothèque (et là, cela dépend complètement du format de celle-ci,
statique ou partagée, dynamique ou pas, etc.)
Cela ne marche pas (pas plus que le truc ci-dessus) si la bibliothèque
utilise un allocateur intermédiaire, par exemple (c'est surtout le cas pour
les machins « orientés objet ») alloue plein de petits morceaux à partir
d'un gros bout qu'elle pique une seule fois au système. Vu de l'extérieur,
seul le gros bout passe par la mécanique malloc()/free(), les petits
morceaux sont gérés entièrement à l'intérieur de la bibliothèque, donc
inaccessibles.
2ième méthode : avec un tableau int tab[10],
sizeof(tab)/sizeof(tab[0]) me donne la taille du tableau.
Mmm, non, pas vraiment.
L'écriture sizeof tab/sizeof tab[0] est un "truc", pas une fonctionnalité ;
la fonctionnalité, c'est sizeof, à savoir une primitive du compilateur qui
donne la taille d'un objet ; et le compilateur le déduit du type que tu lui
as indiqué juste au-dessus, ici « tableaux de 10 entiers » (resp. «
entier »).
Pour pouvoir appliquer cette logique à ton cas, il faut auparavant que tu
explicites au compilateur... quel est le type du tableau, autrement dit lui
dire la taille du tableau.
Comme c'est la donnée que tu cherches, on se mord la queue.
J'ai un pointeur sur un tableau à deux dimensions.
int ** tab;
ce pointeur est initialisé dans une librairie, à laquelle je n'ai pas accès. Puis-je savoir par un quelconque moyen quelle est la taille du tableau à deux dimensions ?
[La taille totale, pas la taille de la dimension intermédiaire, j'espère.]
C'est de la bidouille, mais la réponse est oui.
Pour pouvoir effectuer l'opération free(), sans que l'on dise à free quelle est la taille du bloc précédemment alloué, il faut un peu de /magie/. Cette magie est créee par malloc(). La forme exact de la magie dépend de l'implémentation de malloc() utilisée, mais le détail est en général accessible à travers de fonctions et structures supplémentaires, souvent documentées dans l'entête (non standard évidemment) <malloc.h>.
1ère méthode : compiler en mode débug et déduire la taille du tableau du fait que de chaque coté se trouve des bits de guarde pour éventuellement vérifier les débordements d'indice. -> trés dépendant de l'archi.
Un truc plus simple qui marche bien est de lier ta bibliothèque avec ta propre version de malloc(), et dans l'implémentation de celle-ci faire tous les petits calculs que tu veux, par exemple enregistrer la taille des blocs alloués, les imprimer au passage, les garder dans une liste chaînée pour vérifier qu'il n'y a pas de blocs qui restent alloués sans appel ultérieur à free() etc. Évidemment, il faut _aussi_ que ta propre version de malloc() fournisse l'allocation dynamique :-)
Ce truc (généralement baptisé « debugging malloc library ») a été souvent utilisé, donc il y a pas mal de choses de ce genre qui traînent sur internet. Il faut juste choisir une version qui soit liable à ta bibliothèque (et là, cela dépend complètement du format de celle-ci, statique ou partagée, dynamique ou pas, etc.)
Cela ne marche pas (pas plus que le truc ci-dessus) si la bibliothèque utilise un allocateur intermédiaire, par exemple (c'est surtout le cas pour les machins « orientés objet ») alloue plein de petits morceaux à partir d'un gros bout qu'elle pique une seule fois au système. Vu de l'extérieur, seul le gros bout passe par la mécanique malloc()/free(), les petits morceaux sont gérés entièrement à l'intérieur de la bibliothèque, donc inaccessibles.
2ième méthode : avec un tableau int tab[10], sizeof(tab)/sizeof(tab[0]) me donne la taille du tableau.
Mmm, non, pas vraiment. L'écriture sizeof tab/sizeof tab[0] est un "truc", pas une fonctionnalité ; la fonctionnalité, c'est sizeof, à savoir une primitive du compilateur qui donne la taille d'un objet ; et le compilateur le déduit du type que tu lui as indiqué juste au-dessus, ici « tableaux de 10 entiers » (resp. « entier »).
Pour pouvoir appliquer cette logique à ton cas, il faut auparavant que tu explicites au compilateur... quel est le type du tableau, autrement dit lui dire la taille du tableau. Comme c'est la donnée que tu cherches, on se mord la queue.
Antoine
AG
la méthode 1 marche pas parce que pratiquement aucune librairie C
n'inclut de canaries.
Je ne sais pas ce que vous appelez des canaries, mais si c'est bien ce que j'ai décrit dans mon post précédant, je témoigne que le compilo Visual C++ de Microsoft, en mode DEBUG, ajoute des guardes de part et d'autre du buffer alloué.
Et je sais connais quelques librairies (efence par exemple) utilise ce mécanisme.
AG.
la méthode 1 marche pas parce que pratiquement aucune librairie C
n'inclut de canaries.
Je ne sais pas ce que vous appelez des canaries, mais si c'est bien ce
que j'ai décrit dans mon post précédant, je témoigne que le compilo
Visual C++ de Microsoft, en mode DEBUG, ajoute des guardes de part et
d'autre du buffer alloué.
Et je sais connais quelques librairies (efence par exemple) utilise ce
mécanisme.
la méthode 1 marche pas parce que pratiquement aucune librairie C
n'inclut de canaries.
Je ne sais pas ce que vous appelez des canaries, mais si c'est bien ce que j'ai décrit dans mon post précédant, je témoigne que le compilo Visual C++ de Microsoft, en mode DEBUG, ajoute des guardes de part et d'autre du buffer alloué.
Et je sais connais quelques librairies (efence par exemple) utilise ce mécanisme.