format interne des pointeurs

**gorgonite** · 12/03/2007, 18h02

Salut,

Je me demande juste quel est le format "interne" dans lequel sont stockées les pointeurs dans la machine... je pensais qu'il s'agissait du type int dans mon cas (cpu intel 32 bits) ; mais après affichage, des valeurs de pointeurs avec le format %d je me retrouve avec un pointeur négatif

si quelqu'un comprend...

nb: je n'ai fait que stocker les pointeurs, sans faire d'opérations dessus

**Gruik** · 12/03/2007, 18h32

Ce sont des entiers 32 bit non signés
Or %d affiche un entier signé. Si l'adresse était superieure à 0x7fffffff, alors c'est normal que ça apparaisse comme un entier negatif
Utilise %p ou %lu

**Thierry Chappuis** · 12/03/2007, 18h42

Le code de fonction()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void fonction(void)
{
    int a = 100;
    int *p_int = &a;
 
    (void) p_int;
}

donne chez moi le code assembleur suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
.globl fonction
        .type   fonction, @function
fonction:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $16, %esp
        movl    $100, -8(%ebp)
        leal    -8(%ebp), %eax
        movl    %eax, -4(%ebp)
        leave
        ret

En interne avec gcc sur un processeur Intel PIII, il n'y a aucune différence entre la représentation d'un int et d'un pointeur.

Sinon, du point de vue compilateur, ce sont deux types différent. Cela n'a aucun sens de dire qu'un pointeur est représenté en interne par un int ou par un int non-signé. Tout ce qu'on peut dire, c'est que sur mon architecture particulière, la valeur contenue par un pointeur est stockée sur 32 bits.

Pour de l'affichage avec printf(), un pointeur a son propre spécificateur de format: %p.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
void fonction(void) 
{  
    int a = 100; 
    int *p_int = &a;   
    printf("La valeur de a est stockée sur la pile à l'adresse %p\n", (void *) p_int);
}

Thierry

**gorgonite** · 13/03/2007, 10h21

Envoyé par mujigka

Cela n'a aucun sens de dire qu'un pointeur est représenté en interne par un int ou par un int non-signé. Tout ce qu'on peut dire, c'est que sur mon architecture particulière, la valeur contenue par un pointeur est stockée sur 32 bits.

désolé de te contredire, mais cela a un sens...

surtout quand on passe par des correspondances de Galois pour analyser un code.

J'expose plus précisemment mon problème

J'ai des données stockées dans un grand tableau (alloué par une bibliothèque dont je n'ai pas le source), je parcours mon tableau, et je sélectionne certains patterns et j'enregistre dans un tableau que j'ai crée les pointeurs correspondants aux valeurs intéressantes...

toutes mes valeurs sont dans la plage 0x80[7-8]* sauf une qui est 0xb7d83372, sachant que cela ne devrait pas avoir lieu... etant donné la relativement petite taille du tableau de valeurs initial

quelqu'un saurait-il comment cela peut se produire ?

[EDIT]
sachant que si j'essaie d'accéder à la valeur qui serait stockée à la dite adresse je déclenche un SIGSEGV
donc j'essaie d'accéder à un bout de mémoire qui ne m'est pas destiné...

**koala01** · 13/03/2007, 12h27

Salut,

Pour rappel, un pointeur, c'est une variable qui est un peu particulière en cela qu'elle contient... une adresse mémoire...

Il est donc logique d'estimer, les adresses mémoire commençant à ... 0 (pas d'adresse -123

) que l'on travaille sur des valeurs non signées

Comme les variables sont connues du processeur par leur adresse, il n'y a rien d'étonnant au fait que celle qui indque "l'adresse à laquelle commence le tableau" ne soit pas forcément à proximité... du début du tableau

D'autant plus que, si le tableau en lui meme prend la place sur le tas, il est vraissemblable que "la variable qui prend l'adresse du tableau" prenne place, elle... sur la pile

(ou est-ce l'inverse

)

**Emmanuel Delahaye** · 14/03/2007, 10h59

Envoyé par Gruik

Ce sont des entiers 32 bit non signés

... sur une machine donnée. Ce n'est pas une généralité. Je connais des pointeurs 16-bits... Et je ne serais pas étonné qu'ils fassent 64-bit sur les nouvelles architectures Intel...

Or %d affiche un entier signé. Si l'adresse était superieure à 0x7fffffff, alors c'est normal que ça apparaisse comme un entier negatif
Utilise %p ou %lu

"%p" uniquement, sinon, le comportement est indefini. Et il faut un (void*).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
   int x; 
   int *p = &x;
 
   printf ("%p\n", (void*) p);

**gorgonite** · 14/03/2007, 11h08

Envoyé par koala01

Comme les variables sont connues du processeur par leur adresse, il n'y a rien d'étonnant au fait que celle qui indque "l'adresse à laquelle commence le tableau" ne soit pas forcément à proximité... du début du tableau

D'autant plus que, si le tableau en lui meme prend la place sur le tas, il est vraissemblable que "la variable qui prend l'adresse du tableau" prenne place, elle... sur la pile

(ou est-ce l'inverse

)

normalement, n'y a-t-il pas utilisation de mémoire virtuelle de façon à obtenir un bloc contigu lors de l'allocation... ?

parce que là en gros, si j'essaie de parcours le tableau du premier pointeur à la fin... ben ça passe par une zone interdite, et tout plante

un peu dans ce genre

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
BYTE* list;
while (*list++) {
   ...
}

quelqu'un verrait-il une autre solution peu couteuse ?

nb: mon tableau fait environ 34 000 * sizeof(unsigned char)

**Emmanuel Delahaye** · 14/03/2007, 11h57

Envoyé par gorgonite

parce que là en gros, si j'essaie de parcours le tableau du premier pointeur à la fin... ben ça passe par une zone interdite, et tout plante

Si un pointeur a une valeur interdite, c'est qu'il y a un comportement indéfini dans ton programme, c'est tout.

Il faut corriger le bug.

**gorgonite** · 14/03/2007, 12h00

Envoyé par Emmanuel Delahaye

Si un pointeur a une valeur interdite, c'est qu'il y a un comportement indéfini dans ton programme, c'est tout.

Il faut corriger le bug.

le problème, c'est que ce tableau est généré par une API que je ne controle pas

**jowo** · 14/03/2007, 12h06

Envoyé par gorgonite

J'ai des données stockées dans un grand tableau (alloué par une bibliothèque dont je n'ai pas le source), je parcours mon tableau, et je sélectionne certains patterns et j'enregistre dans un tableau que j'ai crée les pointeurs correspondants aux valeurs intéressantes...

toutes mes valeurs sont dans la plage 0x80[7-8]* sauf une qui est 0xb7d83372, sachant que cela ne devrait pas avoir lieu... etant donné la relativement petite taille du tableau de valeurs initial

REMARQUE:
Ta bibliothèque autorise-t-elle d'accéder directement à un élément de son tableau ou dois-tu (par contrat ou par description de la documentation) y accéder seulemnet via une fonction de la bibliothèque?

**gorgonite** · 14/03/2007, 12h08

Envoyé par jowo

REMARQUE:
Ta bibliothèque autorise-t-elle d'accéder directement à un élément de son tableau ou dois-tu (par contrat ou par description de la documentation) y accéder seulemnet via une fonction de la bibliothèque?

directement... ils me fournissent le BYTE* tab et je dois me débrouiller sans connaitre la longueur

**jowo** · 14/03/2007, 12h12

Envoyé par gorgonite

directement... ils me fournissent le BYTE* tab et je dois me débrouiller sans connaitre la longueur

Utiliser un tableau sans connaître sa longueur. C'est de la barbarie.

Comment sais-tu que tu arrives à la fin de ton tableau?

**gorgonite** · 14/03/2007, 12h16

Envoyé par jowo

Utiliser un tableau sans connaître sa longueur. C'est de la barbarie.

Comment sais-tu que tu arrives à la fin de ton tableau?

pas besoin... en fait, je lis les motifs, et seulement sur certains motifs, je continue la lecture. à la fin, on a un motif pour terminer, et on quitte

**jowo** · 14/03/2007, 12h58

Envoyé par gorgonite

pas besoin... en fait, je lis les motifs, et seulement sur certains motifs, je continue la lecture. à la fin, on a un motif pour terminer, et on quitte

La seule raison pourquoi ton mécanisme ne fonctionne pas est tu ne détectes pas correctement le "motif de fin".

Sans code et sans autres informations sur la biblio, il est diffcile de t'aider plus

**gorgonite** · 14/03/2007, 13h33

Envoyé par jowo

La seule raison pourquoi ton mécanisme ne fonctionne pas est tu ne détectes pas correctement le "motif de fin".

Sans code et sans autres informations sur la biblio, il est diffcile de t'aider plus

je pense aussi... donc j'essaie de ruser en récupérant l'adresse du pointeur à la fin de la lecture par leur fonction "test" de parcours

pour les sources, je ne peux malheureusement pas les fournir... trop longues, trop de fichiers dans tous les sens ; et surtout, je ne pense pas avoir l'autorisation

**souviron34** · 14/03/2007, 13h49

juste une petite question :

ton adresse "singulière", ça serait pas par hasard l'adresse interne où est stockée l'adresse du tableau (ce qui expliquerait que tu n'y aies pas accès) ??

Exemple :

Si ils ont déclaré :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
static double *MONTABLEAU=NULL ;
 
...
 
MONTABLEAU = malloc (N);
....

Tu pourras sans doute d'après leur fonction accèder à l'adresse pointée par MONTABLEAU, mais certainment pas à la variable MONTABLEAU.

**gorgonite** · 14/03/2007, 13h55

non j'ai vraiment accès à cette variable, et je peut la manipuler à ma guise...

cf while(*tab++)

**souviron34** · 14/03/2007, 13h57

ce que je voulais dire, c'est :

es-tu sûr que cette adresse correspond à ton tableau ???

**gorgonite** · 14/03/2007, 14h02

Envoyé par souviron34

ce que je voulais dire, c'est :

es-tu sûr que cette adresse correspond à ton tableau ???

ben je lis des données cohérentes avec ce que j'attends... donc ça doit etre lui

**jowo** · 14/03/2007, 14h40

Comment as-tu programmé le parcours de ton tableau?

Une possibilité est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
BYTE *table = NULL;
BYTE *liste;
BYTE elmnt;
 
table = BiblioMaFonction();
if (table != null) {
    liste = table;
    while (*liste != FIN_DE_LISTE) {
        /* traitement d'un élément de la liste */
        elmnt = *liste;
        /* élément suivant */
        liste++;
    }
}
free(table);

Le code pour le parcours est simple. Il se peut que l'erreur provienne du traitement d'un élément de la liste (corruption des données internes du tableau table).

format interne des pointeurs

C

Discussions similaires

Partager

Partager