Reprise du message précédent :
 
ouais, c'est quand même un peu fou que l'on puisse apprendre le B.A BA alors qu'on code régulièrement en C (même si c'est pas du tout mon boulot), pourquoi permettre un pointeur sans initialisation si c'est aussi dangeureux...?
Bon, ceci dit, maintenant, j'ai un autre problème qui n'a rien à voir, mais ma fonction lecture_param ne me renvoie plus les bonnes valeurs, "smtp" contient la même valeur que "destinataire" (je régresse ! ça marchait très bien ça !), encore un résultat farfelu ça...je vais corriger ça fissa, j'ai du faire des erreurs dans les malloc  

Utiliser des variables non initialisées invoque un comportement indéfini.
 
Un comportement indéfini est un des pires bugs qui soit. En effet, le comportement étant imprévisible, il peut arriver n'importe quoi, y compris un comportement visible normal.  
 
Il est donc impossible de le détecter de façon certaine à l'exécution. Aucun test unitaire ne peut en venir à bout à 100%.
 
C'est, je le répète, la pire peste du programmeur quel que soit le langage. Mais le C en compte de centaines tapis dans l'ombre qui n'attendent que le moment propice pour sauter à la gorge du pauvre programmeur...
 
Pour éviter ça, il faut très bien connaitre le langage pour les repérer au premier coup d'oeil, et appliquer certaines regles de bonne conduite comme toujours donner une valeur valide (ou NULL) à un pointeur. C'est particulièrement vrai dans les structures contenant des pointeurs...
 
Comme je dis souvent, mais qui est en général mal compris :
 
"Le C n'est pas un langage de débutant"
 

mais justement, ne m'as-tu pas dit dans un précédent message que donner une valeur NULL a un pointeur n'était pas une solution puisque si on le passe en paramètre d'une fonction ce sera une adresse non valide ?
 
edit: problème arrangé, j'avais mal initialisé un pointeur sur char...

Bienvenu dans le monde merveilleux du C. Tu as lu ma devise :  
 
"C is a sharp tool"
 
En voilà une autre :  
 

 
Je crois que je vais bientôt en faire des T-shirts...

malloc() n'est pas la panacée. J'ai indiqué 3 méthodes d'initialisation des pointeurs. Autre solution utiliser un tableau...

Décidemment, j'ai du mal à te suivre    
Autre solution, utiliser un tableau pour éviter malloc ? Mais justement, j'utilise justement malloc pour initialiser mes tableaux (le tableau de struct tm par ex) comme mes pointeurs...je sais bien qu'un tableau est un pointeur pointant vers l'adresse du premier élément, mais ça m'aide pas à saisir là...

Dans mon code, il y aurait eu un  

Ca calme...
 
Ca permet d'avoir un comportement défini, même si ce n'est pas celui qu'on attend. Encore une fois, l'ennemi absolu du programmeur, le Diable, le Démon, la Peste, c'est le comportement indéfini. Ca rentre ou il faut que j'aille chercher le gros marteau ?
 

décidemment, nos réponses sont en oppositions de phase ! Je poste ce message sans autre question en cas que tu répondes à mon précédent message et que le petit manège continue...
Pour le marteau, merci pour la proposition, mais je vais essayer de rentrer ça autrement  

Ca, c'est une énormité.
 
Avant tout, il faut créer le tableau. Pour ça il y a 2 méthodes (on va faire simple, OK?)
 
Le tableau statique qui existe sous 4 formes :  

Le tableau dynamique crée par malloc (ou calloc ou realoc)

Ah, ben justement, avant je faisait la dernière version du statique, et pour résoudre mon problème je suis passez à la version dynamique. Si j'ai bien compris, ça n'a servi à rien, la version statique numero 4 est parfaitement correcte et le problème ne venait pas des tableaux...?
 
edit: pourtant, si, quand je repasse en déclaration statique, le programme plante comme avant, donc c'est bien de là que venait le problème !  
Dans le main, si j'initialise comme ça:

ça plante ! Si je fais:

ça marche ! Je dois encore mal saisir un truc là ??

Ca dépend de la valeur de MAX. Les gros tableaux en local, ça plante, c'est normal. Je l'avais déjà signalé...

MAX vaut 500, c'est pas non plus monstrueux. Puis dans tous les cas, que ce soit avec la première méthode ou la seconde, y'a MAX qui intervient dans l'allocation de la mémoire, donc si c'était trop gros, les deux planteraient non ?

C'est gros.

quand même, c'est pas rien..

Ben non. Dans le cas du tableau statique , les 500 * sizeof (struct tm) bytes sont pris dans le mémoire automatique qui est une ressource restreinte et incontrôlable, d'où le risque de plantage (on est pas prévenu).
 
Dans le deuxième cas, un pointeur occupe quelques bytes (2, 4...) dans la mémoire auto et le bloc alloué est pris dans la mémoire dynamique qui peut être énorme. En cas d'erreur, malloc() retourne NULL.  
 
"Everything is under control."

Hum, c'est effectivement plus subtil que ce que je pensais.
Cependant, je me souviens avoir testé avec MAX petit (genre 2), et ça plantait quand même, ce n'est pas un problème de mémoire. Ca m'intrigue ce plantage sauvage lorsque les tableaux sont définis en statique et qui disparait dès qu'on le fait en dynamique...

Il y avait peut être autre chose. J'ai pas dit 'ça plante', j'ai dit 'c'est gros'. Nuance...
 

je sais bien   . Mais moi, je le dis: lorsque je remplace  

au tout début du main par:

boum, ça fait un crash sauvage lors de l'exécution de "lecture_params" qui pourtant n'a rien à voir avec tm_tab !! Si ça c'est pas incompréhensible...en tout cas ça me titille sévère, parceque ça veut dire que je pourrais etre confronté à ce problème sans savoir ce qu'il se passe...

J'insiste : ça ne veut pas dire que la cause réelle n'est pas ailleurs...

de toute façon, cela vient sans doute d'ailleurs, on a jamais vu une déclaration statique raisonnable planter comme ça, c'est vraiment n'importe quoi...ça doit etre truffé de bugs, va falloir que je me colle à un debugage intensif...

Bon, je suis arrivé après la bataille. Tout ce qui peut être dit l'a été
 

Ou alors, s'il n'est pas trop gros, poste ton code dans son intégralité qu'on puisse poser un doigt vainqueur sur la ligne 123 en disant "c'est là"...

ben il est quand même pas petit, il doit bien faire 500 lignes (bien sûr y'a plus gros, mais bon je vais pas caser 500 lignes dans un post quand même). Puis j'ai bien peur de me faire traiter de tout pas les puristes du C (ils se reconnaitront   ) qui trouveront 1000 choses à redire à mon code (dont la source du plantage !) et me sommeront d'arrêter de coder, de prendre un bouquin avant de jouer au programmeur, et moultes choses désagréables...
 
Je vais essayer de me débrouiller et si je trouve des indications plus précises sur le plantage, je vous en ferais part  

Oui, ce n'est pas évident.
Quand j'ai un gros problème, j'essaye de refaire un programme similaire mais plus petit et de n'y laisser que les lignes liées au problème...
 

Oui, moi aussi parfois je ressens ça et j'hésite souvent à donner du code sur le forum. Et pourtant je ne me considère pas comme un débutant...

ben tout le problème est là: je ne peux pas préjuger de d'ou viens le problème justement, c'est tellement irréaliste comme comportement que ça peut venir de n'importe quoi, et je serais contraint de poster tout le code...
En tout cas merci pour tout, si je mets le doigt dessus de manière un peu plus préçise, je ferais appel à vos lumières à tous !

C'est peut-etre le bon moment pour apprendre a utiliser un debugger.

ah, ça, je dois bien avouer que c'est quelque chose qui m'est totalement étranger...

Ton problème qui apparait en statique et pas en dynamique vient peut être que si on suit ce que tu as marqué au début, tu réassignes au pointeur une nouvelle valeur (qui est pourtant la même que celle du départ). Ca ca marche en statique mais pas en dynamique et on t'a conseillé de mettre void en type de retour à ta fonction et de la lancer sans mettre truc=fonction(...)

En fait, c'est l'inverse, ça marche en dynamique et pas en statique. Le code tout au début du post n'est plus valable, je suis effectivement passé en void pour tout ce qui est saisie, cf quelques posts plus bas...

Montre  la dernière version de ton code qui ne fonctionne pas et décrit clairement les conditions d'essais qui montrent le problème.