Incompatibilité des normes

Version imprimable

06/04/2006, 18h30
PRomu@ld

Incompatibilité des normes

Bonjour, je me permet de poser une question sur une chose qui me chagrine.

Je suis tombé sur un article qui proposait la création de plugin en utilisant les fonctions de libdl.

Bon, je vais pas vous faire un long speach sur l'utilisation de ces fonctions mais pour l'utilisation de dlsym, il y a un problème ...

dlsym me renvoie un pointeur void * et il faut effectuer un cast par un pointeur de fonction pour récupérer la fonction de la bibliothèque que l'on vient de charger pour pouvoir utiliser cette fonction.

Cependant, un cast d'un pointeur void* en un pointeur de fonction n'est semble t'il pas autorisé par la norme (en tout cas c'est ce que me dis gcc).

Alors il y a une chose qui m'embête : dlsym semble être POSIX donc normalisé mais ne semble donc pas être compatible avec les normes du C. Il n'y aurait pas contradiction ?
:cfou:

Je prend l'exemple de dlsym mais il doit y en avoir d'autres.

Si quelqu'un a une explication ou même une solution pour contourner le problème ça m'interresse ...
06/04/2006, 18h34
gangsoleil
Bonjour,

J'ai utilisé dlsym dans un programme, et ne me souviens pas avoir eu de problèmes particuliers.
Code:

1 2 3 func_name = (int (*) (char * usrName , char * grpName, int usrId, int grpId, int mode) ) dlsym(profile_handle, "getMyProfile");
Peux-tu poster le code qui te pose problème ?
06/04/2006, 18h36
Franck.H

Moi j'ai préféré utiliser les fonctions de la GLib pour ca ... en plus c'est portable "sans" problèmes :wink:

Alors voilà le test que j'ai :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 #include <stdio.h> #include <stdlib.h> #include <dlfcn.h> int main (void) { void *handl; int (*func) (void *); func = (int (*) (void *)) dlsym(handl, "exemple"); return EXIT_SUCCESS; }
Lorsque je compile j'obtiens :

Citation:

test.c: In function 'main':
test.c:10: warning: ISO C forbids conversion of object pointer to function pointer type
test.c:10: warning: 'handl' is used uninitialized in this function

Bon le deuxième warning est normal, je n'ai pas appelé dlopen, mais l'exemple est là pour se concentrer sur le problème.

06/04/2006, 18h56
Emmanuel Delahaye

Re: Incompatibilité des normes

Citation:

Envoyé par PRomu@ld

dlsym me renvoie un pointeur void * et il faut effectuer un cast par un pointeur de fonction pour récupérer la fonction de la bibliothèque que l'on vient de charger pour pouvoir utiliser cette fonction.

Vu de la norme, le comportement est indéterminé. Dans la pratique, si la doc te dis de faire comme ça, c'est que sur la plateforme concernée, le comportement est défini.
06/04/2006, 18h58
Emmanuel Delahaye

Citation:

Envoyé par PRomu@ld

Citation:

test.c: In function 'main':
test.c:10: warning: ISO C forbids conversion of object pointer to function pointer type

C'est sûr que ce n'est pas une pratique standard. Pour l'utiliser il faut être moins restrictif.

Il y a des cas où on ne peut pas écrire du code strictement conforme. Ces cas doivent être documentés et le comportement expliqué.
06/04/2006, 19h00
PRomu@ld

Citation:

Dans la pratique, si la doc te dis de faire comme ça, c'est que sur la plateforme concernée, le comportement est défini.

Je suis bien d'accord mais ça ne te dérange pas toi ? En tout cas, moi si ! Les warnings me dérangent surout pour me dire que ce que je fais n'est pas sensé être autorisé par la norme ... Si encore la bibliothèque avait été crée par un petit amateur peu scrupuleux des normes ça ne m'aurait pas dérangé mais là la fonction est POSIX tout de même ...

Citation:

Moi j'ai préféré utiliser les fonctions de la GLib pour ca ... en plus c'est portable "sans" problèmes

Je vais aller voir ça.
06/04/2006, 19h07
Emmanuel Delahaye

Citation:

Envoyé par PRomu@ld

Citation:

Dans la pratique, si la doc te dis de faire comme ça, c'est que sur la plateforme concernée, le comportement est défini.

Je suis bien d'accord mais ça ne te dérange pas toi ? En tout cas, moi si ! Les warnings me dérangent surout pour me dire que ce que je fais n'est pas sensé être autorisé par la norme ...

La norme dit que le comportement dépend de l'implémentation. Donc, ça peux fonctionner. Le problème des pointeurs de fonctions est qu'il n'y a pas de pointeur de fonction générique. Cette solution un peu batarde a été trouvée, mais elle n'est pas portable, c'est tout. Dans les cas où les conditions sont réunies (par exemple, un pointeur sur objet a la même taille qu'un pointeur sur fonction), le fonctionnement est garanti.

Il vaut mieux des warnings explicables que pas de warnings parce qu'on a baissé le niveau de diagnostic.
06/04/2006, 19h13
PRomu@ld

J'ai juste lu l'entête de la documentation des fonctions de la glib :

Citation:

The current implementation supports all systems that provide an implementation of dlopen()

Ca commence bien ...

Citation:

Il vaut mieux des warnings explicables que pas de warnings parce qu'on a baissé le niveau de diagnostic.

Oui, d'accord, de toute façon il faudra bien que je m'en contente ...
06/04/2006, 23h33
loufoque

Essaie de passer par un size_t sinon.
06/04/2006, 23h40
Emmanuel Delahaye

Citation:

Envoyé par loufoque

Essaie de passer par un size_t sinon.

Un size_t pour faire quoi ?
07/04/2006, 08h58
Jean-Marc.Bourguet

Re: Incompatibilité des normes

Citation:

Envoyé par PRomu@ld

Alors il y a une chose qui m'embête : dlsym semble être POSIX donc normalisé mais ne semble donc pas être compatible avec les normes du C. Il n'y aurait pas contradiction ?

Je ne vois pas de contradiction. La norme C specifie un certain nombre de choses et en laisse d'autres volontairement indeterminees. Posix complete la norme C en specifiant une partie de ces choses indeterminees, mais a ma connaissance ne demande rien que la norme C ne permet pas. Donc Posix est compatible avec le C.
07/04/2006, 10h35
PRomu@ld

Citation:

warning: ISO C forbids conversion of object pointer to function pointer type

Je ne suis pas un expert en anglais mais il me semble que forbid ça veut dire interdire, non ?

Nous ne sommes plus dans l'indéterminé, ou alors c'est gcc qui s'avance là dessus...

Une fonction POSIX ferait donc une chose que le C interdit, ça n'est donc pas complèter la norme c'est passer outre, en tout cas c'est comme ça que je le vois.
07/04/2006, 10h47
Emmanuel Delahaye

Citation:

Envoyé par PRomu@ld

Nous ne sommes plus dans l'indéterminé, ou alors c'est gcc qui s'avance là dessus...

Je pense que gcc a grossi le trait... Ca mérite un rapport de bug...
07/04/2006, 11h02
PRomu@ld

En regardant sommairement dans la base bugzilla de gcc, je n'ai rien trouvé faisant mention de ceci, peut-être un rapport à faire donc.

Par contre sur google je suis tombé là dessus :

http://www.trilithium.com/johan/2004/12/problem-with-dlsym/

La fin me parait interressante :

Citation:

The Open Group page on dlsym indicates that a future version may either add a new function to return function pointers, or the current interface may be deprecated in favor of two new functions: one that returns data pointers and the other that returns function pointers.

Et effectivement le problème est expliqué :

http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html

Et visiblement c'est gcc qui exagère, comme tu le disais :

Citation:

The result of converting a pointer to a function into a pointer to another data type (except void *) is still undefined,
07/04/2006, 11h07
Emmanuel Delahaye

Citation:

Envoyé par PRomu@ld

Par contre sur google je suis tombé là dessus :

http://www.trilithium.com/johan/2004/12/problem-with-dlsym/

C'est clair que la solution est là, mais il faudrait unifier les types retour, ou supporter un cast...
07/04/2006, 11h48
PRomu@ld

Citation:

par exemple, un pointeur sur objet a la même taille qu'un pointeur sur fonction

je comprend bien la chose. Il ne faudrait pas forcément avoir la même taille, si le pointeur de fonction a une taille inférieure, ça le fait aussi (mais est-ce possible ?)

Citation:

http://www.trilithium.com/johan/2004/12/problem-with-dlsym/

Là dedans, dans les solutions "probables" en attendant une éventuelle sépartation en deux de dlsym, il parle de "union cast", j'avoue ne pas trop voir le rapport, ou alors je ne vois pas du tout à quoi il est fait référence, as-tu des infos là dessus ?
07/04/2006, 11h56
Emmanuel Delahaye
Citation:

Envoyé par PRomu@ld

Là dedans, dans les solutions "probables" en attendant une éventuelle sépartation en deux de dlsym, il parle de "union cast", j'avoue ne pas trop voir le rapport, ou alors je ne vois pas du tout à quoi il est fait référence, as-tu des infos là dessus ?

une horreur comme ça, je suppose...
Code:

1 2 3 4 5 6 7 8 union fun_ptr { void *p; int (*fp_int)(); void (*fp_void)(); /* etc. */ };
07/04/2006, 12h03
PRomu@ld

Citation:

warning: ISO C forbids casts to union type

:mouarf2:
07/04/2006, 18h59
loufoque

Citation:

Envoyé par Emmanuel Delahaye

Citation:

Envoyé par loufoque

Essaie de passer par un size_t sinon.

Un size_t pour faire quoi ?

C'est l'une des solutions citées.

Citation:

You could resort to a variety of tricks to avoid the direct object/function pointer cast:

* casting via an integral type

* "union cast" (set one member of a union, get another)

* memcpy
07/04/2006, 19h15
PRomu@ld

La deuxième solution ne me convient pas, ça consisterait à remplacer un warning par un autre (ayant la même signification : ISO C forbids ...)

Tu voudrais donc caster en un type entier ? Mais pouquoi un size_t en particulier ? de plus je ne connais pas la norme mais le problème semble revenir au même : il faut que le type entier soit de taille suppérieure ou égale à la taille d'un pointeur sur un objet ...
07/04/2006, 21h31
fearyourself

Citation:

Envoyé par PRomu@ld

il faut que le type entier soit de taille suppérieure ou égale à la taille d'un pointeur sur un objet ...

Ce qui n'est pas toujours le cas:

Citation:

Envoyé par Itanium 2

Taille int: 4
Taille void*: 8

Jc
07/04/2006, 21h35
PRomu@ld

C'était bien ce que je pensais !

Sur les trois solutions proposées, deux sont donc impossibles, reste à voir la troisième : le memcpy, je n'ai pas le temps de tester mais si quelqu'un s'en sent l'envie ...

Ceci fonctionne (avec memcpy, et en passant par un void* intermediaire) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dlfcn.h>
 
int main (void)
{
  void *handle, *vp;
  char *error;
  double (*cosine)(double);
 
  handle = dlopen ("libm.so", RTLD_LAZY);
  if (!handle) {
    fprintf (stderr, "%s\n", dlerror());
    exit(1);
  }
 
  vp = dlsym(handle, "cos");
  if ((error = dlerror()) != NULL)  {
    fprintf (stderr, "%s\n", error);
    exit(1);
  }
  memcpy (&cosine, &vp, sizeof cosine);
 
  printf ("%f\n", (*cosine)(2.0));
  dlclose(handle);
 
  return EXIT_SUCCESS;
}
 
/* EOF */

Citation:

$ gcc -Wextra -Wall -ansi -pedantic -O2 -ldl ./tt.c

08/04/2006, 21h00
loufoque

size_t fait la même taille que void*...
08/04/2006, 21h46
Emmanuel Delahaye

Citation:

Envoyé par loufoque

size_t fait la même taille que void*...

Ce n'est absolument pas garanti pas la norme.
08/04/2006, 22h46
loufoque

Je crois que c'est valable d'après POSIX.
Au pire y'a uintptr_t.

2°)

Citation:

warning: ISO C forbids casts to union type

Euh... Tu essaies de caster directmeent le résultat en union? Ce n'est pas ça, un "union cast": c'est de faire:
Code:

1 2 3 4 union fun_ptr ufp; ptrfonction_t pt_f; /* Un pointeur du type exact de la fonction voulue */ ufp.p = dlsym()... pt_f = (ptrfonction_t)ufp.fp_int; /* Je ne sais plus si ici, un cast sera nécessaire ou non */
3°) Je pense qu'uintptr_t est préférable à size_t.
Mais en effet, je crois bien que size_t est voué à avoir la même taille qu'un pointeur (c'est le cas sous Win32/64, et c'était le cas sous DOS (un size_t avait la taille d'un pointeur court, le type normal de pointeur. Mais pour un pointeur long, il fallait utiliser un entier long)). Et puis, uintptr_t est directement convertible pour porter un programme sous Windows (un petit typedef UINT_PTR uintptr_t; et ça compile sans problème)

09/04/2006, 08h41
PRomu@ld

Citation:

Euh... Tu essaies de caster directmeent le résultat en union? Ce n'est pas ça, un "union cast": c'est de faire:

Ok merci bien ! Dsl pour l'erreur, j'avais pas vérifié ce que je faisais, en fait c'était plutôt idiot ! (En période de révision, l'attention est ailleur ...)

Citation:

Mais en effet, je crois bien que size_t est voué à avoir la même taille qu'un pointeur

C'est dans la norme ou pas ? (C pas POSIX).

Mais perso, le memcpy me plait plutôt bien. Il faudra que je vérifie si le système à un pointeur de fonction de taille inférieure ou égale à la la taille d'un pointeur sur objet. (mais ça c'est valable pour toutes les solutions)

Fuseau horaire GMT +2. Il est actuellement 04h41.