Salut,

J'ai remarqué un comportement avec mon programme en 32bits que j'ai pas en 64bits.

Par exemple avec ce genre de structure

typedef Foo ... ;

struct mastructure
{
   Foo n;
   mastructure* gauche;
   mastructure* droite;
};

Bref typiquement un arbre.

Si je fais ça en 64bits :

struct mastructure* arbre = malloc(sizeof(mastructure));

Ca se suffit à lui même
Alors que pour que ça fonctionne en 32bits (sinon ca fait un segfault)
Je suis obligé de faire

struct mastructure* arbre = malloc(sizeof(mastructure));
arbre->gauche = NULL;
arbgre->droite = NULL;

Bref, je comprend pas trop pourquoi il y a cette nuance entre les 2 versions.
Si quelqu'un a une idée

Ce n'est pas plutot que tu compiles le 32b et 64b dans des modes differents, e.g. debug/release ou similaire, ou certains automatismes sont actifs, notamment le zeroing des allocs ?

Le 29 février 2016 à 19:12:54 LGV a écrit :
Ce n'est pas plutot que tu compiles le 32b et 64b dans des modes differents, e.g. debug/release ou similaire, ou certains automatismes sont actifs, notamment le zeroing des allocs ?

Non non, j'ai même testé sur des machines différentes, avec la même version de GCC et le même makefile

malloc ne garantie pas que la zone memoire soit initialise. C'est un coup de bol.

Le 29 février 2016 à 19:55:10 godrik a écrit :
malloc ne garantie pas que la zone memoire soit initialise. C'est un coup de bol.

Justement dans un projet différent(où je devais manipuler plusieurs mo de mémoire normalement à 0), j'ai eu la même remarque d'un prof.
Or même si j'initialisais pas à 0, toute ma zone, j'ai jamais eu ce problème sur mon ordinateur. Alors je sais pas si c'est une special feature de ma libc ou de GCC mais c'est vraiment étrange, j'ai jamais eu à initialisé à 0.
Mais c'est vrai que ça vient surement de ça.

Ca depend des OS, mais la doc de malloc est clair:
"The malloc() function allocates size bytes and returns a pointer to the allocated memory. The memory is not initialized. If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free()."

Parcontre, certains OS ou certaines implementation de al libc pourrait mettre a 0. de memoire les BSD font ca pour eviter d'avoir la memoire d'une app qui deborde dans une autre.