Pointeurs de fonction et warnings - Page 1

Petite question très conne, mais sur laquelle je bute depuis déjà un peu de temps...
Voilà, j'ai une première fonction qui prend en argument une fonction f et un pointeur quelconque.
void function_stub(void *(*f) (void*), void *arg)

Je veux créer un nouveau contexte et lui donner cette function_stub comme argument.
void makecontext(ucontext_t *ucp, void *func(), int argc, ...);
makecontext(& context, function_stub, 2, f, arg );
Ça crée bien un nouveau contexte, qui va lancer function_stub et lui donner f et arg comme arguments. Tout fonctionne parfaitement, mais j'ai un vilain warning à la compilation.
warning: passing argument 2 of ‘makecontext’ from incompatible pointer type
Et je n'aime pas les warnings

J'ai essayé de faire un
makecontext(& context, (void *) &function_stub, 2, f, arg );
mais il râle encore...

Si j'ai bien compris, c'est parce que le C ne veut pas (le vilain !) qu'on transforme un pointeur de fonction en un pointeur classique (s'il insiste... ).. mais quelle est la façon propre de faire ça ?

Ben c'est normal, dans ta dernière ligne tu lui passes quelque chose de type void* (pointeur vers rien)
or le prototype de ta fonction makecontext demande un pointeur vers une fonction si je ne m'abuse (le deuxième argument est déclaré comme void * func() donc il a le type d'un pointeur vers une fonction qui ne prend pas d'argument et renvoie void, non ?)

il ne suffit pas que dans ton appel à makecontext tu castes le truc vers le bon type ? (c'est-à-dire "pointeur vers void -> void" (je n'ai pas idée de comment ça s'écrit, j'ai jamais rien compris à la syntaxe des types en C))

edit : ah et aussi dans le deuxième cas tu lui passes &function_stub alors que dans le premier tu lui passes function_stub, c'est une erreur de recopiage ?

Je suis plutôt d'accord avec toi, mais je n'ai pas trouvé comment écrire pointeur vers void* -> void* c'est pour ça que j'ai testé pointeur vers n'importe quoi

(cross-edit)
il me semble que Kevin Kofler doit savoir (peut-être Pollux aussi mais il est pas là), seul un mutant peut comprendre cette syntaxe

J'ai trouvé ça :
http://portal.acm.org/ft_gateway.cfm?id=947627&type=pdf&coll=GUIDE&dl=GUIDE&CFID=18027&CFTOKEN=95817462
bon en fait ça explique rien

je dirais que "pointeur vers void*->void*" doit ressembler à void*(*)(void*) mais un peu au pif

Sally (./4) :
seul un mutant peut comprendre cette syntaxe

c'est absolument illisible.

Flanker, à ta place je ferais quelques typedefs, ça aide à y voir plus clair. Y'a d'ailleurs des trucs que j'ai jamais réussis à faire avaler au compilo autrement qu'en les cassant en petits morceaux avec des typedefs.

(au fait, c'est pas payant ACM Portal, d'habitude ? ^^)

Yeaaaaah ! merci Sally !
En m'inspirant de ton truc (il me semble que je l'avais essayé, en fait), j'ai essayé (void (*) (void) ) et ça marche

(bon, je ne comprends pas trop pourquoi le tien ne marche pas, mais bon, spa grave )

0² > euh pas si j'y vais depuis le réseau de l'université en tous cas, mais sinon ptêt ouais ^^

Ben là j'ai pu télécharger le fichier que tu as mis en lien, mais généralement je tombe sur ce site via Google, et à chaque fois il n'y a qu'un court extrait, faut avoir un compte (payant j'imagine) pour avoir l'intégralité.

EDIT : ah ben, apparemment, maintenant on ne peut plus télécharger avec ton lien, le site propose d'acheter l'article. C'est intéressant, ça veut dire qu'ils font la gestion de leurs sessions uniquement avec l'URL

Flanker (./7) :

En m'inspirant de ton truc (il me semble que je l'avais essayé, en fait), j'ai essayé (void (*) (void) ) et ça marche

(bon, je ne comprends pas trop pourquoi le tien ne marche pas, mais bon, spa grave )

Ben c'est normal, c'est pas les mêmes proto.

Si tu définis proprement makecontext :
void function_stub(void *(*f) (void*), void *arg);
void makecontext(ucontext_t *ucp, void (*func)(void *(*)(void*),void*), int argc, ...);

ton appel passe sans aucun cast.
makecontext(& context, function_stub, 2, f, arg );
et l'utilisation de function_stub dans makecontext se ferra sans cast.

pas forcément utile après la bataille mais quand même:

http://www.newty.de/fpt/fpt.html

bref c'est tellement merdique que parfois c'est plus compréhensible de passer par un typedef.

j'arrive plus à le retrouver mais y'a un outil en ligne de commande qui sert à décrire des types, genre tu lui donnes un

int *

et il te répond "pointer to integer"

et ça marche aussi pour les trucs hyper tordus

PpHd: ces déclarations

PpHd (./10) :

Flanker (./7) :

En m'inspirant de ton truc (il me semble que je l'avais essayé, en fait), j'ai essayé (void (*) (void) ) et ça marche

(bon, je ne comprends pas trop pourquoi le tien ne marche pas, mais bon, spa grave )

Ben c'est normal, c'est pas les mêmes proto.

Si tu définis proprement makecontext :
void function_stub(void *(*f) (void*), void *arg);
void makecontext(ucontext_t *ucp, void (*func)(void *(*)(void*),void*), int argc, ...);

ton appel passe sans aucun cast.
makecontext(& context, function_stub, 2, f, arg );
et l'utilisation de function_stub dans makecontext se ferra sans cast.

Vi, j'ai réalisé ça ce soir, en prenant mon vélo pour rentrer

void (*func)(void *(*)(void*),void*) est un pointeur de fonction qui ne retourne rien et qui prend deux arguments, le premier est un pointeur de fonction qui retourne un pointeur sur rien et qui prend comme argument un pointeur sur rien, le second est un pointeur sur rien.

je penserai à toi si j'ai des soucis de types

parfois, j'en viens à penser que finalement, le Ocaml est clair

squalyl (./11) :
j'arrive plus à le retrouver mais y'a un outil en ligne de commande qui sert à décrire des types, genre tu lui donnes un

int *
et il te répond "pointer to integer"

Y'a une version (limitée) de ce truc-là comme programme d'exemple dans le K&R, comme quoi même les auteurs devaient réaliser à quel point c'était indigeste

Bof, lorsque tu en es à faire des prototypes ressemblant à :
void (*g(void (*)(void*)))(void (*)(void (*)(void *)));
faut avoir un peu compris comment çà marche

Ou les faire de façon heuristique

Voici le même genre qui renvoie ce qu'il prend en entrée

void (*identity(void (*h)(void (*)(void (*)(void*)))))(void (*)(void (*)(void *)))
{
  return h;
}

(Without any warnings of course !)

Et moi qui pensait me mettre au C un jour, l'assembleur c'est du basic à côté ...

on a rarement besoin de trucs aussi compliqués, hein

Certes mais ils avaient globalement un peu trop fumé avant de définir la syntaxe (ça c'est juste un des pires exemples, mais même la syntaxe de base est à chier. C'est LE gros inconvénient du C, d'ailleurs ^^ — sinon conceptuellement c'est pas trop mal comme langage de bas niveau, c'est pour ça que c'est utilisé d'ailleurs)

Sally (./2) :
edit : ah et aussi dans le deuxième cas tu lui passes &function_stub alors que dans le premier tu lui passes function_stub, c'est une erreur de recopiage ?

si je ne me trompe pas, en C, f et &f désigne la même chose quand f est une fonction.

C'est bien possible, parce que les deux fonctionnent

squalyl (./11) :
j'arrive plus à le retrouver mais y'a un outil en ligne de commande qui sert à décrire des types, genre tu lui donnes un

dans le bouquin de K & R, il y a les sources de ce programme
(à moins que ça ne soit qu'une version plus limitée)

Cf ./16 ^^

Flanker (./1) :
void makecontext(ucontext_t *ucp, void *func(), int argc, ...);

Ici, func est de type void *()...

makecontext(& context, (void *) &function_stub, 2, f, arg );

... et ici tu castes vers void * seulement, c'est pour ça que tu as toujours un warning. (Un pointeur de fonction n'est pas garanti être représentable par un void *, donc la conversion automatique de void * en un pointeur sur n'importe quoi ne s'applique pas aux pointeurs de fonction.)

Mais la bonne solution est celle donnée par PpHd dans le post ./10.

C'est quand même vachement plus lisible avec des typedefs...

++Link;

c'est quand meme vachement plus lisible avec n'importe quel langage non prehistorique, et qui a compris qu'imposer au developpeur d'ecrire lui meme les types alors que le compilateur peut les intuiter tout seul, c'est grotesque.

meme le c++ va bientot avoir le keyword auto, c'est dire...