Appel de fonction à arguments variables - Page 2

Ben perso, de temps en temps, cygwin se bloque. Et puis la lenteur des scripts le rend vite inutilisable.
Sinon cf post ./16

Cygwin se bloque ?!?

Pour ./16, ben ils sont bien obligés de garder l'API de Windows, évidemment... Tu vois Linux supprimer toute compatibilité ascendante pour changer son API ? Ou pour passer à l'API Windows ? ...

Ca n'empeche pas le reste que je sache

bon si j ai bien compris, tu cherches a utiliser une fonction prototypee comme ca :

type_alpha ma_fonction(type_beta param1 ,type_gamma param2 ,type_delta param3);

avec type_alpha, type_beta, type... etant soit void, soit ... etc
tu peux definir une structure comme ceci:

#define struct {
    char type;          /* caractere representant le type de l element pointé par ptr, fixe par une convention que tu definis */
    void* ptr;          /* pointeur a caster en fonction de type ( attention si c est un type void ... ) */
} ens_type;

ta fonction devient donc :

ens_type ma_fonction(ens_type param1, ens_type param2, ens_type param3)

Le problème c'est qu'avec cette méthode, je suis obligé de passer tous les arguments à la fois, et non pas un par un. A moins de se dire que "une fonction ne pourra pas avoir plus de N paramètres" et de faire un gros switch, ça n'ira pas je crois.

t'as pas répondu à ./28, d'ailleurs...

En survolant votre tro... hem ... discussion, j'ai pas vu de "?", il y avait une question furtive dans le #27 ? (et si la question c'est la dernière phrase du #27, qui n'est pas une question, bah je capte pas donc ça va être difficile de répondre quoi que ce soit )

ben j'ai fait des suppositions ("si"), je sais pas lesquelles s'appliquent dans ton cas... (est-ce que c'est pour des fonctions vararg ou pas ? / est-ce que c'est uniquement pour appeler du code que vous avez écrit vous-même ?)

oui, mais le but de la maneuvre était de pvoir appeller des fonctions quelconques, non "préparées" pour cet usage spécifique.

ben il va falloir en plus forcer la convention d'appel du compilo pour que ça soit un truc genre cdecl, sinon ça peut pas marcher ^^

sinon solution parfaitement portable mais crade, faire un script qui extrait du code source la liste des fonctions appelables avec le type des arguments, puis qui génère tous les appels possibles pour les mettre dans une fonction C; genre :

void DrawLine(int x1,int y1,int x2,int y2);
void DrawStr(int x,int y,char *s);

=>

void call_function(void *func) {
  // str pointe vers la liste des arguments
  if (func==DrawLine)
    DrawLine(get_int(str),get_int(str),get_int(str),get_int(str));
  else if (func==DrawStr)
    DrawStr(get_int(str),get_int(str),get_charptr(str));
}

Hmm oui mais le but final est d'appeller des fonctions d'une dll depuis un interpreteur de scripts, donc pas de code source :/

Vertyos :
Hmm oui mais le but final est d'appeller des fonctions d'une dll depuis un interpreteur de scripts, donc pas de code source :/

Mais t'as quand même un header avec des prototypes, donc tu peux générer à partir de là.

Mais comment "génerer" tous les appels possibles, même en connaissant les prototypes des fonctions ?

Pollux> libffi permet de construire totalement l'appel, depuis le premier paramètre jusqu'à la récupération de la valeur de retour. Le compilateur ne se permet pas de passer des paramètres par registres à moins qu'on le lui demande explicitement (en tous cas c'est vrai avec GCC, le compilo de billou et celui de borland). Dans tous les cas une fonction exportée par une DLL suit la convention stdcall, qui est la convention standard pour les dll (enfin on peut forcer le compilo à faire autrement mais ....).

Enfin, libffi est maintenue par les développeurs de GCC, et je soupçonne qu'ils connaissent le fonctionnement de leur propre compilateur.

Vertyos> ah oui, libffi est dépendente de GCC il me semble, donc bah euh faut faire avec. De toutes façons si tu fais un truc non portable, le plus simple c'est encore d'y aller comme un porc et de faire l'appel en assembleur x86 directement.

hmm mwé sauf que je connais pas le x86, et que le prog est censé tourner sur mac aussi (et en priorité, même )
je sens que ça va être simple cette histoire... ^^

et donc tu compiles avec GCC/make et compagnie ?
!shoot Vertyos

Si c'est du GCC, libffi marchera sans problème (enfin sans problème autre que d'arriver à l'utiliser.

Bon je viens de tester :
- d'une part y'a un exemple de petit prog utilisant libffi pour construire des appels à puts dans le README
- et le code suivant fonctionne correctement =>

#include <stdio.h>
#include <ffi.h>

typedef void(*func)();

int fonction(int a, char * b)
{
	printf("a=%d / b = %s\n", a, b);
	return a+1;
}

int main(int argc, char * argv[])
{
	ffi_cif cif;
	ffi_type * args[2] = {
		&ffi_type_sint,
		&ffi_type_pointer
	};
	
	void * values[2] = {
		&argc, &argv[0]
	};

	if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 2, &ffi_type_sint, args) == FFI_OK)
	{
		int result;
		ffi_call(&cif, (func)fonction, &result, values);
		
		printf("result = %d\n", result);
	}
	
	return 0;
}

spectras@etherflow:~/prog/divers$ ./testffi
a=1 / b = ./testffi
result = 2

- une fois le cif préparé, on peut l'utiliser autant de fois qu'on veut. Le cif sert de prototype. Tu peux l'utiliser pour appeler toute fonction ayant un prototype identique, une fois qu'il est prêt.
- d'après quelques recherches rapides sur le net, libffi marche très bien avec mingw (faut juste vérifier que c'est la même version que le gcc, mais normalement y'a pas de raison que ce soit une version différente

oki, ça a l'air déjà bcp plus clair que le prog de "test" de 16ko. il me reste plus qu'à chopper un ffi.h correct pr tester ça, mci