a priori avec une lib dynamique, le point d'entré de la fonction est calculé à l'exécution (adresse de chargement + offset probablement) puis enregistré dans un pointeur de fonction. et ensuite c'est ce pointeur de fonction qui sera utilisé.

Je crois que vous méritez tous mieux que de l'assembleur inline pour plonger aux tréfonds du langage C.

Je vous offre ici quelque chose qui est certainement une extension gcc du C, mais c'est tellement beau ...

http://repository.sectionpc.info/C/change_eip2.c

Faire de l'arithmétique des pointeurs avec des adresses de code c'est amusant.

Bon, mais avec ça comme avec la version assembleur, c'est assez difficile d'écrire quoi que ce soit car même avec toutes les optimisations désactivées, gcc essaye d'éliminer les bouts de code mort et il a du mal à comprendre les saut en assembleur ou avec la technique que je montre ici et il supprime des bouts de code utile.

Par contre, je suis assez content car ça montre que contrairement à ce que j'ai cru, finalement, on n'a pas trop besoin de redescendre au plus bas niveau pour faire ce genre d'acrobatie.

cette extension du C est ce qui s'appelle les "computed gotos" et que gcc appel "labels as values".

En guise de conclusion (temporaire) pour ce topic j'ai croisé par hasard une autre méthode qui permet de faire à peu près la même chose, c'est l'appel système sigsetjmp (posix, on doit pouvoir le trouver dans certaine version de windows, même si je n'en suis pas sûr). Il permet de sauver le contexte du programme. Puis n'importe où, on peut appeler siglongjmp et on retourne à l'endroit exacte où avait été fait l'appel à sigsetjmp.

Les sauts non locaux existent en C:
http://www.linux-kheops.com/doc/man/manfr/man-html-0.9/man3/setjmp.3.html

Si ça peut t'aider...

oui, setjmp est quasiment la même chose que sigsetjmp que j'évoquais dans mon précédant message, sauf que l'état des signaux n'est pas forcément sauvé.