Bonjour/soir à tous.

Je rencontre actuellement un problème quand à l'utilisation de listes chainées.
L'exercice consiste actuellement à "découper" un texte en lignes (puis ces lignes en expression, puis caractère...Mais ça n'a pas d'importance ici).
J'ai donc une structure line.
struct line
{
expr* e;
line* nxt;
};
Tout fonctionne bien. Le programme compile et s'exécute sans encombres.

Mais ce n'est pas suffisant, maintenant je veux avoir un champs contenant la longueur de la ligne.
struct line
{
int cols;
expr* e;
line* nxt;
};
Lorsque je modifie mon .h comme ci dessus, ça compile, ça s'exécute...suivi de près par un segfault.

Histoire de m'assurer que c'est bien ça qui pose problème, je compile le code suivant un peu à l'arrache.

line* l;
l = malloc(sizeof(line));
printf("%p\n",l);
l = lpush(l);
l = l->next;
printf("%p\n",l);

Voici les résultats obtenus avec et sans le champs "cols":

Sans:
0x8ec3888
0x8ec4568

Avec:
0x908d888
(nil)

Alors la je pige plus rien.
Quelqu'un à une idée?

donne plus de contexte.

C'est quoi le code de lpush ?

Tu as bien recompilé tout ton projet et pas juste le fichier de test après tes modifs ?

Tu n'as aucune erreur ni aucun warning à la compilation ? et tu utilises bien les options pour signaler un max de warning genre "-Wall -Wextra" pour gcc) ?

lpush->
Je ne sais pas si ma rédaction est naïve, je suis assez mauvais juge de mon propre travail, et il s'agit de mon premier "gros" projet.

line* lpush(line* head)
{
int num;
struct line* pnew = malloc(sizeof(line));
pnew->next = NULL;
pnew->expr = malloc(sizeof(expr));
struct line* parc = head;
if(head == NULL)
{
return pnew;
}
else
{

while(parc->next != NULL)
{
parc = parc->next;
}
num = parc->numero + 1;
pnew->numero = num;
parc->next = pnew;
return head;
}
}

Je recompile bien tout le projet.

Avec les options Wall OU Wextra j'obtiens énormément de messages d'erreurs de définitions multiples

...
test: In function `__data_start':
(.data+0x0): multiple definition of `__data_start'

/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/
crt1.o:(.data+0x0): first defined here
...
/tmp/ccYsCTIF.o:(.data+0xa0): multiple definition of `str'
test:(.data+0xc0): first defined here
...
list.o: In function `empty':
list.c:(.text+0x273): multiple definition of `empty'
test:(.text+0x327): first defined here
...

Et ce pour, apparemment, la plupart (si ce n'est toutes) les variables et fonctions déclarées.

« Avec les options Wall OU Wextra j'obtiens énormément de messages d'erreurs de définitions multiples »
cherche pas plus loin, il est là ton (premier ?) problème.

Vu que tu sembles bosser avec des fichiers séparés, je suppose qu'on t'a déjà expliqué les trois règles d'or :
1) pas de code dans un .h
2) ne jamais inclure de .c avec #include
3) pour toto.h, faire un truc du genre :

1. ifndef __TOTO_H__
2. define __TOTO_H__

<déclarations pour toto.h>

1. endif

Merci pour la réponse rapide et à cette heure tardive

Mes .h ne contiennent que des déclarations.
En revanche, j'y ai aussi déclaré des variables globales.
La encore, je n'ai jamais eu à m'en servir avant. Peut être m'y suis-je mal pris.
J'ai bien protégé mes en-têtes contre les inclusions multiples.
Je n'inclue aucun .c comme tu l'as cité.

J'ai quand même tenté de compiler sans les variables globales citées plus haut. J'obtiens les mêmes erreurs.

donne le code complet.

D'abord je tiens à m'excuser de mon code un peu cochon.
(Ne me frappez pas, j'ai écrit pas mal de fonctions analogues, mais je corrigerai ça plus tard.)
Et il est bien sur incomplet.
Ensuite, j'ai mis lpush au dessus, dans mon code la fonction s'appelle new_line.
Les lignes 26 à 37 du fichier test illustrent le problème cité.

En descendant :
list.c
http://codeviewer.org/view/code:103b
list.h
http://codeviewer.org/view/code:103a

file.c
http://codeviewer.org/view/code:103c
file.h
http://codeviewer.org/view/code:103d

edit.c
http://codeviewer.org/view/code:103e
edit.h
http://codeviewer.org/view/code:103f

test.c
http://codeviewer.org/view/code:1040

En revanche, j'y ai aussi déclaré des variables globales. ça je le considère comme du code malheureusement.

Ton soucis, c'est que dans chacun de tes .o tu vas avoir de la mémoire prévue pour tes variables globales. Du coup, quand tu veux recompiler le tout, conflit.

ligne 89-90 de list.h tu veux sans doute faire une fonction init qui utilisera des variables globales dans list.c.

J'ai commenté les deux lignes auxquelles tu faisais allusion.
J'ai toujours la même erreur lors de la compilation.

M'enfin dans ma tête, une déclaration de variable globale, c'était tout comme la déclaration d'une fonction. Non?

oui, mais une fonction tu ne la déclare qu'une seule fois, dans un fichier .c et c'est pareil pour les variables globale que tu mets une seule fois dans un fichier source. Ensuite, dans les en-têtes, tu mets les "prototypes" des variables globales, i.e. la "déclaration" de la variable, mais précédée du mot clef extern.

dnob700->
Merci pour l'explication, j'étais loin du compte.
Cela dit, même en supprimant totalement ces déclarations (je ne faisait encore aucun usage de ces variables), les erreurs de compilation persistent.

dnob700 : mouais pour le extern.

Mais je reste convaincu que grosse_nouille ferait mieux de mettre ses variables dans son .c et de fournir de quoi manipuler leur contenu via des fonctions. C'est quand même moins obscur de faire comme ça. (bon, c'est aussi moins efficace sans doute.)

Mais puisque je m'en suis simplement débarrassé

Tu parles bien des déclarations sur les deux lignes que tu avais souligné plus haut, non?

Puis je viens juste de remarque ça...
/home/.../test.c:9: multiple definition of `main'
test:/home/.../V2/test.c:9: first defined here

C'est normal docteur?

non, ce n'est pas normal. Est-ce que tu ne donnerais pas deux fois le même fichier à ton compilo ?

+1000 à dnob.

Pour moi, tous tes problèmes ont un point en commun : une phase de compilation cagneuse.

Comment tu compiles ton projet ?

«2) ne jamais inclure de .c avec #include»

Mince, désolé pour la fausse manip.

Je voulais juste dire qu'elle était en plaqué or celle là, avec un ou deux exemples de métaprog en tête utilisant des inclusions croisées de .c et .h. C'est tout à fait horrible, mais bien efficace une fois que ça roule.

Dnob700 & Chris27->

Je compile comme ceci:

gcc -c list.c
gcc -c files.c
gcc -c edit.c

gcc -g -o -Wall test list.o files.o edit.o test.c -lncurses

Comme je l'ai dit, j'ai bien protégé mes fichiers contre les inclusions multiples.

gcc -g -o -Wall test list.o files.o edit.o test.c -lncurses
heu… tu voulais pas dire :
gcc -g -Wall -o test list.o files.o edit.o test.c

Parce que -o suivi de -Wall ça m'a l'air assez vaseux comme truc.