Interchangeabilité des types pointeur

Le
Jérôme Frgacic
Bonjour à tous,

Tout d'abord, meilleurs vœux pour cette année 2013.

Dans le cas d'un petit projet personnel, je souhaite crée une liste dont =
chaque nœud comporte un pointeur vers une ressource allouée et un point=
eur de fonction spécifiant la fonction permettant de libérer cette ress=
ource. Ainsi, j'ai représenté un nœud à l'aide de cette structure :

struct ressource {
void *data;
void (*delete)();
struct ressource * next;
};

Le problème, c'est que les ressources allouées sont stockées au sein =
d'un pointeur générique (pointeur sur void), mais que les fonctions de =
destructions référencées, elles, n'attendent pas forcément un tel p=
ointeur (parfois oui, comme free, mais parfois non, comme fclose ou autre).=
Je sais que, à ce sujet, la norme fourni quelques garanties pour certain=
s types de pointeurs :

C11 (n1570), § 6.2.5 Types, al. 28, p. 43
> A pointer to void shall have the same representation and alignment
> requirements as a pointer to a character type. Similarly, pointers
> to qualified or unqualified versions of compatible types shall have
> the same representation and alignment requirements. All pointers to
> structure types shall have the same representation and alignment
> requirements as each other. All pointers to union types shall have the
> same representation and alignment requirements as each other. Pointers
> to other types need not have the same representation or alignment
> requirements.

mais pour le reste, rien n'est prévu. Aussi, j'aurais voulu savoir si j'a=
i des chances de tomber sur des architectures où une telle solution pose =
problème et, également, s'il existe une autre solution, cette fois-ci p=
ortable ?

Merci d'avance pour vos réponses.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
espie
Le #25118942
In article Jérôme Frgacic
Bonjour à tous,

Tout d'abord, meilleurs vœux pour cette année 2013.

Dans le cas d'un petit projet personnel, je souhaite crée une liste dont
chaque nœud comporte un pointeur vers une ressource allouée et un
pointeur de fonction spécifiant la fonction permettant de libérer cette
ressource. Ainsi, j'ai représenté un nœud à l'aide de cette structure :

struct ressource {
void *data;
void (*delete)();
struct ressource * next;
};

Le problème, c'est que les ressources allouées sont stockées au sein
d'un pointeur générique (pointeur sur void), mais que les fonctions de
destructions référencées, elles, n'attendent pas forcément un tel
pointeur (parfois oui, comme free, mais parfois non, comme fclose ou
autre). Je sais que, à ce sujet, la norme fourni quelques garanties pour
certains types de pointeurs :

C11 (n1570), § 6.2.5 Types, al. 28, p. 43
A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type. Similarly, pointers
to qualified or unqualified versions of compatible types shall have
the same representation and alignment requirements. All pointers to
structure types shall have the same representation and alignment
requirements as each other. All pointers to union types shall have the
same representation and alignment requirements as each other. Pointers
to other types need not have the same representation or alignment
requirements.



mais pour le reste, rien n'est prévu. Aussi, j'aurais voulu savoir si
j'ai des chances de tomber sur des architectures où une telle solution
pose problème et, également, s'il existe une autre solution, cette
fois-ci portable ?



Il ne reste pas grand chose dans "le reste"... ca couvre les pointeurs
de fonction, en fait. C'est le cas un peu bizarre en C, mais tant que
tu ne manipules que des pointeurs sur autre chose que du code, tout
ceci est tres portable.

Pour le reste, cote cast entre pointeurs, tu peux avoir des problemes
d'aliasing si tu ne passes pas un des types etiquette comme "pointeur
generique", c'est-a-dire void*, char* et assimiles. Donc dans ton cas,
zero probleme.
Antoine Leca
Le #25120542
Jérôme Frgacic écrivit :
Le problème, c'est que les ressources allouées sont stockées au sein d'un
pointeur générique (pointeur sur void), mais que les fonctions de
destructions référencées, elles, n'attendent pas forcément un tel pointeur
(parfois oui, comme free, mais parfois non, comme fclose ou autre). Je
sais que, à ce sujet, la norme fourni quelques garanties pour certains
types de pointeurs :

C11 (n1570), § 6.2.5 Types, al. 28, p. 43


[couic]

mais pour le reste, rien n'est prévu.



Euh, si. 6.3 /Conversions/, § 6.3.2.3 /Pointers/, al. 1 :
A pointer to void may be converted to or from a pointer to any
object type. A pointer to any object type may be converted to
a pointer to void and back again; the result shall compare
equal to the original pointer.

En gros, tant que ton code manipule des pointeurs génériques et que
derrière il y a des pointeurs vers des types _objets_, tout va bien.
Il faut bien comprendre que si dans ton code tu écris
FILE* f;
ptr_ress->data = f;
il y a conversion de FILE* à void* ; et quand tu écris plus tard
fclose( (FILE*)(ptr_ress->data) );
la conversion de retour (/back/) est même explicite !


En règle générale les représentations et les alignements sont bien
entendu identiques ; mais dans les cas où il y a des différences (genre
des pointeurs vers char sur 48 bits quand un pointeur vers struct est
sur 32 bits; ou les pointeurs _far* ou _segment* qui firent la joie des
programmeurs PC des années 1985-1990...), c'est le problème du
compilateur, pas celui de la norme, ni du programmeur qui la suit.


Antoine
espie
Le #25120722
In article Antoine Leca
FILE* f;
ptr_ress->data = f;
il y a conversion de FILE* à void* ; et quand tu écris plus tard
fclose( (FILE*)(ptr_ress->data) );
la conversion de retour (/back/) est même explicite !



En C, tu n'as pas besoin de la conversion de retour. J'aurais meme tendance
a dire qu'elle est nefaste, puisqu'elle peut masquer une erreur si ton
type de depart n'est pas un pointeur.

Je sais que c'est sans doute une mauvaise habitude heritee du C++, ou meme
une envie de faire dans la compatibilite gratuite.

J'aurais bien envie de dire que si vraiment tu veux la compatibilite,
ca vaut le coup de cacher ca derriere une macro:

#ifdef __cplusplus
#define voidp_cast(T, v) reinterpret_cast<T>(v)
#else
#define voidp_cast(T, v) (v)
#endif

fclose(voidp_cast(FILE *, ptr_ress->data));
Jean-Marc Bourguet
Le #25121062
(Marc Espie) writes:

Je sais que c'est sans doute une mauvaise habitude heritee du C++, ou meme
une envie de faire dans la compatibilite gratuite.



Ou simplement l'idee que c'est plus logique de marquer les conversions
non sures ;)

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
espie
Le #25121882
In article Jean-Marc Bourguet
(Marc Espie) writes:

Je sais que c'est sans doute une mauvaise habitude heritee du C++, ou meme
une envie de faire dans la compatibilite gratuite.



Ou simplement l'idee que c'est plus logique de marquer les conversions
non sures ;)



... mais plus dangereux, puisque ton compilo acceptera aussi bien.

void *p;
struct a *q;
q = (struct a *)p;


que
int p;
struct a *q;
q = (struct a *)p;


...
J
Le #25121872
Antoine Leca a écrit :
Euh, si. 6.3 /Conversions/, § 6.3.2.3 /Pointers/, al. 1 :
A pointer to void may be converted to or from a pointer to any
object type. A pointer to any object type may be converted to
a pointer to void and back again; the result shall compare
equal to the original pointer.

En gros, tant que ton code manipule des pointeurs génériques et que
derrière il y a des pointeurs vers des types _objets_, tout va bien.
Il faut bien comprendre que si dans ton code tu écris
FILE* f;
ptr_ress‐>data = f;
il y a conversion de FILE* à void* ; et quand tu écris plus tar d
fclose( (FILE*)(ptr_ress‐>data) );
la conversion de retour (/back/) est même explicite !



En fait, mon problème est que la libération de la ressource est f aite
via le pointeur de fonction « delete » de la structure. Autrement dit,
pour chaque ressource, on a un appel du type :

ptr_ress‐>delete(ptr_ress‐>data);

Or, si cela ne pose pas de problème quand la fonction référe ncée est
free, c’est plus gênant s’il s’agit de fclose car elle reçoit un objet
de type « pointeur sur void » alors qu’elle attend un obj et de type «
pointeur sur structure ».

Je me demande donc si une telle technique pose, de manière génà ©rale,
un problème (appremment non) et s’il n’existe pas une alternative qui
ne pose pas de problèmes de portabilité.

Marc Espie a écrit :
Il ne reste pas grand chose dans "le reste"... ca couvre les pointeurs
de fonction, en fait. C’est le cas un peu bizarre en C, mais tan t que
tu ne manipules que des pointeurs sur autre chose que du code, tout
ceci est tres portable.



Ben, disons que, en théorie, il reste : les pointeurs sur tous les
types natifs (sauf void et char), les pointeurs de pointeur, les
pointeurs sur tableau et les pointeurs de fonction.

Mais, si je comprend bien, dans la réalité, tous les pointeurs on t
généralement la même taille sauf les pointeurs de fonctions ?
espie
Le #25121982
In article Jérôme Frgacic
Marc Espie a écrit :
Il ne reste pas grand chose dans "le reste"... ca couvre les pointeurs
de fonction, en fait. C’est le cas un peu bizarre en C, mais tant que
tu ne manipules que des pointeurs sur autre chose que du code, tout
ceci est tres portable.



Ben, disons que, en théorie, il reste : les pointeurs sur tous les
types natifs (sauf void et char), les pointeurs de pointeur, les
pointeurs sur tableau et les pointeurs de fonction.



Non, il faut que tu relises attentivement ce que la norme appelle un objet
dans ce contexte precis.

Ca couvre tout sauf les pointeurs de fonction...
J
Le #25122272
Non, il faut que tu relises attentivement ce que la norme appelle un
objet dans ce contexte precis.

Ca couvre tout sauf les pointeurs de fonction...



J’avoue que je suis un peu perdu là... Lorsque je lis ce pass age :

A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type. Similarly, pointers to
qualified or unqualified versions of compatible types shall have the
same representation and alignment requirements. All pointers to
structure types shall have the same representation and alignment
requirements as each other. All pointers to union types shall have the
same representation and alignment requirements as each other. Pointers
to other types need not have the same representation or alignment
requirements.



Je comprends que la norme nous garantit que, ont la même taille et le
même alignement :

‐ un pointeur sur char et un pointeur sur void ;
‐ un pointeur sur un type et un pointeur sur le même type qualifié ;
‐ un pointeur sur structure et un pointeur sur une autre struct ure ;
‐ un pointeur sur union et un pointeur sur une autre union.

Pour le reste, la norme ne nous dit rien, ce qui signifie, pour moi,
que rien ne me garantit qu’un pointeur sur une structure à la même
taille et le même alignement qu’un pointeur sur void et que, p ar
conséquent, le code suivant a un comportement indéterminé :

#include
struct coord {
int x;
int y;
};

static void print_ptr();

int
main(void)
{
struct coord coord;
struct coord *p = &coord;

print_ptr(p);
return 0;
}


static void
print_ptr(void *p)
{
printf("%pn", p);
}


me trompé‐je ?
espie
Le #25122342
In article Jérôme Frgacic
Non, il faut que tu relises attentivement ce que la norme appelle un
objet dans ce contexte precis.

Ca couvre tout sauf les pointeurs de fonction...



J’avoue que je suis un peu perdu là... Lorsque je lis ce passage :

A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type. Similarly, pointers to
qualified or unqualified versions of compatible types shall have the
same representation and alignment requirements. All pointers to
structure types shall have the same representation and alignment
requirements as each other. All pointers to union types shall have the
same representation and alignment requirements as each other. Pointers
to other types need not have the same representation or alignment
requirements.



Je comprends que la norme nous garantit que, ont la même taille et le
même alignement :

â€
Antoine Leca
Le #25123902
Marc Espie écrivit :
In article Antoine Leca
FILE* f;
ptr_ress->data = f;
il y a conversion de FILE* à void* ; et quand tu écris plus tard
fclose( (FILE*)(ptr_ress->data) );
la conversion de retour (/back/) est même explicite !



En C, tu n'as pas besoin de la conversion de retour. J'aurais meme tendance
a dire qu'elle est nefaste, puisqu'elle peut masquer une erreur si ton
type de depart n'est pas un pointeur.



Très juste, cela m'avait échappé.


Antoine
Publicité
Poster une réponse
Anonyme