Discussion :

[guillaume-13015]

Bonjour,

je rencontre un problème assez étrange, j'ai une structure UserInfo :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
typedef struct _UserInfo
{	
char Name[256];
char Email[256];
char TelephoneMobile[50];
char  TelephoneMobile[50];
 
long BadLoginCount;
bool IsAccountLocked; 
 
time_t PasswordExpirationDate;
time_t LastLogin;
 
 
}   UserInfo;

J’utilise cette structure dans une DLL crée sous Visual C++ 2010 Express
et les fonctions de cette DLL sont utilisées dans un programme compilé sous GCC dans Code::Block. (par chargement explicite de la dll)

exemple : GetUserInfoAD(UserInfo *ret)

le problème c'est que dans cette fonction les valeurs sont correctement attribuées a la structure,
mais dans mon projet quand j'utilise la fonction de ma dll et que j'affiche les valeurs, j'ai les 4 char ( Name,Email, TelephoneMobile, TelephoneMobile) qui sont correctement affiché, mais les autres variables ( BadLoginCount,BadLoginCount,PasswordExpirationDate;LastLogin)
non.

En faite j'ai remarqué que selon dans quel ordre je déclare les variables dans ma structure, valeurs changent ou sont inversées entre les variables !
J'ai bien tenté de trouver la bonne combinaison mais j'ai toujours une variable qui n'a pas la bonne valeur .
Je précise que je re-compile bien sur, la DLL et l'EXE à chaque fois que je modifie la structure.
J'ai lu que les compilateurs effectuent des modifications au seins de la structure ( padding ?)

comment faire pour uniformiser la structure entre les deux compilateurs ? ou faire en sorte de forcer la même optimisation?

merci beaucoup d'avance,

cordialement

[transgohan]

Sous certains compilateurs microsoft tu peux le configurer avec #pragma pack(n).

[Neckara]

Bonjour,

Sous certains compilateurs microsoft tu peux le configurer avec #pragma pack(n).

C'est dommage de rendre le code moins portable ( #pragma n'étant pas standard et pas accepté par tous les compilateurs ) pour cela.

De plus, je sais qu'en C++ il y a des incompatibilité entre les compilateurs au niveau des .dll car certains aspects comme l'héritage ne sont pas gérés de la même manière.
Je ne demande donc si en C on ne peut pas avoir d'autres problèmes de ce type (?).
Je pense que la meilleure solution serait de se créer un petit cmakeLists.txt et de compiler le projet pour chaque compilateurs qu'on souhaite utiliser (?).
Ceci permettrait peut être (?) d'éviter de mauvaises surprises.

[transgohan]

Il n'existe pas de solution portable de toute manière (hormis des hacks, voir en bas de mon post).

La norme c++11 défini alignas : http://en.cppreference.com/w/cpp/language/alignas
Mais ce n'est pas supporté par les compilateurs microsoft.

Un post intéressant sinon : http://stackoverflow.com/questions/6...ulate-alignast

Edit :
Avec GCC pour supprimer le padding :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
struct test{
  int a;
  char b;
  int c;
} __attribute__((__packed__));

C'est strictement équivalent au pack(1).
https://www.securecoding.cert.org/co...ucture+padding

Ou bien tu peux explicitement rajouter ton propre padding.

[ram-0000]

c'est un problème de padding.

La solution la plus propre, ne pas rendre visible cette structure et faire dans ta DLL des fonctions qui lisent ou écrivent les valeurs de cette structure.

[Bktero]

J'ai lu que les compilateurs effectuent des modifications au seins de la structure ( padding ?)

Le padding consiste à éventuellement rajouter des bits de remplissage (padding, en anglais) pour respecter des contraintes d'alignements des champs dans la mémoire. En revanche, cela ne change aucunement lors de champs ! Les champs sont placés en mémoire dans l'ordre dans lequel ils sont définis dans le code.

En faite j'ai remarqué que selon dans quel ordre je déclare les variables dans ma structure, valeurs changent ou sont inversées entre les variables !

N'as-tu pas une fonction qui fait un memset() / memcpy() de la structure au lieu de faire une affectation champ par champ ?

[guillaume-13015]

Merci de vos réponses,

bien noté pour le padding, je vais rajouter ça dans mon code partagé entre les deux compilateurs pour éviter les éventuels futur soucis,

une fois ce problème de padding résolu, j'ai eu toujours des problèmes mais seulement avec les "time_t"
je les remplacés par des unsigned int et la ... plus de soucis avec le décalage sur les time_t

donc j'ai testé un sizeof(time_t), un dans la dll et l'autre dans l'exe
et je suis très étonné du résultat :

sizeof(time_t) sous VC++ =8
sizeof(time_t) sous GCC =4

comment cela peut être possible ?

[Neckara]

Merci de vos réponses,

bien noté pour le padding, je vais rajouter ça dans mon code partagé entre les deux compilateurs pour éviter les éventuels futur soucis,

une fois ce problème de padding résolu, j'ai eu toujours des problèmes mais seulement avec les "time_t"
je les remplacés par des unsigned int et la ... plus de soucis avec le décalage sur les time_t

donc j'ai testé un sizeof(time_t), un dans la dll et l'autre dans l'exe
et je suis très étonné du résultat :

sizeof(time_t) sous VC++ =8
sizeof(time_t) sous GCC =4

comment cela peut être possible ?

Soit tu compiles en 64 bits sur VC++ et en 32 sur GCC, soit tu n'utilises pas la même implémentation ( la norme ne donne généralement que des tailles minimales pour les types ).
C'est pour cela que je te conseille, plutôt que d'essayer de bidouiller le code de ta bibliothèque pour qu'une fois compilé avec VC++ il puisse être utilisé par un programme compilé avec GCC de compiler ta bibliothèque avec VC++ pour la version VC++ et avec GCC pour ta version GCC.
Ceci sera beaucoup plus simple, rapide et sûr.

[ram-0000]

sizeof(time_t) sous VC++ =8

Normal :

Under Visual Studio 2008, it defaults to an __int64 unless you define _USE_32BIT_TIME_T. You're better off just pretending that you don't know what it's defined as, since it can (and will) change from platform to platform.

Cf ici : http://stackoverflow.com/questions/4...e-t-typedef-to