Bonjour à tous,

Je travaille sur une appli structurée ainsi :

appli <--> DLLprincipale <--> DLLutilisateur

La majeure partie du code de l'appli est dans la DLL principale. Il y a une bibliothèque que l'utilisateur peut écrire et compiler lui-même pour récupérer le résultat de son calcul perso.

j'appelle donc cette fonction depuis la DLLprincipale :

où tous les paramètres sont des entrées sauf le dernier, pV qui est le résultat du calcul.
l'int de retour est un code erreur.

Ce pointeur pV pointe sur un tableau alloué dans la DLL principale.

Dans la DLL utilisateur on fait :

par exemple.

et voici l'appel :

Le souci c'est que l'appel de cette fonction me donne ceci vu depuis la lib utilisateur:

l'adresse de pV est bidon. Pourtant la fonction est correctement appelée, la mémoire correctement allouée. Et ca plante, évidement. Pourtant pR a bien une adresse correcte... c'est à n'y rien comprendre.

Je me demande si ce n'est pas un souci de flags de compilation et une sombre histoire de pile et de tas. Ou de dépassement mémoire, pourtant j'ai déjà recherché les fuites.

problème de convention d'appel de la fonction, peut-être ?

Qu'est-ce que tu entends par convention d'appel?

edit: ok je pense que c'est un domaine que je ne connais pas, j'y jette un coup d'oeil.

Je doute que ça soit un problème de convention d'appel. Ta fonction doit certainement être un callback, si ce callback n'utilise pas la même convention d'appel, tu auras une erreur à la compilation (sauf si tu cast à l'arrache avec un void *).
 
À vu de nez, ça sent la mauvaise utilisation d'une API et/ou buffer overflow.

Le truc que je capte pas c'est que le paramètre "foat *Pr" qui est une entrée peut être modifié/accédé, alors que "float *pV" qui est alloué de la même manière est dans les choux

 
pas nécessairement, si la convention n'a pas été précisée explicitement dans les header, elle est déterminée par tes options de compilation. Du coup, à l'utilisation si ton projet n'a pas la même convention que celle spécifiée par la DLL, tu ne vois rien à la compilation.
 
Jette donc toujours un coup d'oeil aux stdcall fastcall et cdecl et vérifie, si tu peux, comment est compilée la DLL

Est-ce que vous savez si la valeur du pointeur à 0x1 correspond à un code erreur du noyau?

l'appli est compilée en utilisant ce header :
 

 
la DLL utilise :
 

 
 
Je ne vois absolument aucun flag à la compilation qui pourrait gêner.

les codes d'erreur du kernel, sous windows, sont négatifs lorsque considérés comme int, donc 1 n'est probablement pas un code d'erreur (d'autant plus que je ne vois pas ce qui justifierais son apparition miraculeuse dans une variable comme c'est le cas pour toi en ce moment)
 
Pour tes headers, comme je le pensais, les conventions ne sont pas données clairement.
Cherche un peu dans les propriétés de tes projets. Si l'un est en __cdecl et l'autre en __stdcall, ca pourra donner ce genre de comportement (sous visual studio 2005, c'est dans les propriétés avancées de la seciton C++ du projet)

je vous prie de m'excuser, mais je n'ai pas précisé que j'étais sous UNIX... Cependant tu m'as mis un peu sur la voie et je fais des recherches en ce sens sur le net...

DLL invite plus à penseer Windows, oui, j'ai fait le raccourci
 
UNIX sur x86 ?
S'il t'est possible de débugger en assembler juste avant l'appel de fonction et juste après, pour voir si les données sont bien transmises à l'endroit où on les lit ensuite, ca peut potentiellement te donner des renseignements intéressants

en l'occurrence c'est sous SUN mais j'ai le problème sous Linux aussi. Effectivement ce sont des bibliothèques dynamiques

Je ne sais pas debugger en assembleur...

j'ai trouvé la solution, vraiment évident...

CalculerVariableUtilisateur dans un cas avait 10 paramètres, dans l'autre 11... Comme l'entête est déclaré en externe je suppose que la vérification n'est pas faite à la compilation et édition des liens...

Merci pour votre aide, je vais me cacher...