Memory error bei verketteter Liste !

Marcin

Außerdem ist die Anzahl der gelesenen Zeichen die du an fgets(... ,int num, ...) über gibst um eins zu klein weil fgets num-1 Zeichen ausliest:

fgets(letztes->datum,12,fp); 
fgets(letztes->uhrzeit,7,fp);

Und die Bedingung in der schleife muss lauten aktiv != NULL
und nicht aktiv->next != NULL.

So geändert funktioniert das Programm bei mir.

Den Cast in:

neu = (struct termin*)malloc(sizeof(struct termin));

kannst du auch weglassen.

net 0

Marcin schrieb:

Also bei mir stürtzt sogar der gdb ab

der taugt eh' nix...

GPC

net schrieb:

Marcin schrieb:

Also bei mir stürtzt sogar der gdb ab

der taugt eh' nix...

Echte Programmier brauchen eh keinen Debugger...

Niklas Cathor

elduderado schrieb:

printf("Monat: %s",aktiv->month);
printf("Monat: %s",aktiv->datum);
printf("Monat: %s",aktiv->uhrzeit);
printf("Monat: %s",aktiv->was);

Darf ich fragen, wie der User noch durchblicken soll, wenn sowohl der Monat, als auch das Datum, die Uhrzeit und "was" als Monat ihm dargestellt werden? Ausserdem: Warum wechselst du in den Sprachen? Nenn doch das 1. Teil einfach monat und nicht month... Nur so der Übersichtlichkeit

net:
Wieso meinst du der gdb taugt nix? Das war ein scherz, oder? Ist deine Meinung, will dich auch nicht kritisieren oder so, mich interessiert nur wie du da drauf kommst. Danke.

net 0

Mr.PuMuKEL schrieb:

net:
Wieso meinst du der gdb taugt nix? Das war ein scherz, oder?

hi,
immer wenn ich gdb's verwendet haben, haben die nur rumgezickt. einmal für msp430, dann der, der beim mimgw dabei ist und einmal für ecos/v850. dafür gibts auch noch so schreckliche sachen wie 'insight'. das läuft alles nicht richtig, ist tierisch buggy. liegt wohl daran, dass gdb ein multiplatform debugger ist und sich deshalb nicht so tief in's system eingraben kann wie er's eigentlich sollte. ist ähnlich wie mit'm gcc: gut für unix systeme aber überall anders wird der code 1.5 bis 2 mal so gross und läuft doppelt so langsam im vergleich zu kommerziellen compilern. allgemein gilt: dieser gnu-kram ist irgendwie nur bedingt zu gebrauchen...

Mr.PuMuKEL schrieb:

will dich auch nicht kritisieren oder so

macht doch nix

elduderado

hui, danke an alle .... ja zeiger und Felder können in c echt kompliziert werden aber zum Glück ist die Klausur heute besser gelaufen.

Mit der Ausgabe (Monat), dass war nur ein Flüchtigkeitsfehler. Dank eurer Hilfe läuft es jetzt bei mir. Vielen Dank !!!

Achso @ Marcin: Ich benutze keinen reinen c compiler, sprich Visual C++ und da braucht er den cast, da malloc nur einen *void wiedergibt !!! oder lieg ich da flasch ?!?!?

Marcin

Ich kenne mich zwar mit Visual C++ und dem Compiler den es benutzt zwar nicht aus, aber ich vermute dass es ein C++ compiler ist und deshalb verlangt er unbedingt den cast, ich verstehe dann allerdings nicht warum er nicht gegen void main(), return; protestiert. C++ Compiler sind da viel strenger.
Wie auch immer, in Standard C braucht man kein cast bei malloc weil der Ruckgabewert Zeiger vom Typ void ist und der kann in jeden anderen Zeiger ohne cast umgewandelt werden.

net 0

Marcin schrieb:

Ich kenne mich zwar mit Visual C++ und dem Compiler den es benutzt zwar nicht aus, aber ich vermute dass es ein C++ compiler ist und deshalb verlangt er unbedingt den cast, ich verstehe dann allerdings nicht warum er nicht gegen void main(), return; protestiert. C++ Compiler sind da viel strenger.

beim alten visual c++ (version 6) sind 2 compiler dabei. einer für c und einer für c++. .cpp dateien werden durch den c++ compiler geschickt, deshalb braucht man da ein cast bei void typen. das mit dem 'void main()' stört aber keinen von beiden. ist ja auch nicht wirklich ein problem...

oki vielen Dank schönes weekend allen