Verkettete Liste - merkwürdiger Fehler!
-
BjoernB schrieb:
Hm, es scheint irgendwie mit dem scanf in der while-Schleife zutun zu haben (Zeile 26).
ja, das sieht verdächtig aus. scanf versucht ein einzelnes 'char' mit dem format-code '%ls' zu interpretieren. was immer %ls sein mag, ich kenne nur %s für nullterminierte strings. möglicherweise ignoriert scanf das 'l' und nimmt nur das 's' (standard-kenner bitte berichtigt mich). also, versuchs mal mit '%c' (für ein einzelnes zeichen) statt '%ls'. vielleicht geht's dann.
-
das ist nen %1s, kein %ls. ne eins, nicht das kleine L.
trotzdem gibts da keinen platz für die '\0'.
-
pointercrash() schrieb:
..., heißt, Du überschreibst sonst was anderes.
Bin mit den scanf- Formatstrings selbst nicht so vertraut, aber irgendwo zerhagelt's ihm was, weil er ja den nichtsigen Pointer h (als Platzhalter?) braucht, daß es geht.
Maybe, mal was selber mit getc() zusammennageln?
-
denke auch, das %1s mit nem unsigned char was zerschiessen tut, weil ein byte an speicherplatz fehlt.
-
Hm, also das "%1s" in Verbindung mit unsigned char dürfte meines Wissens nach keine Probleme verursachen...
Bedeutet ja eig. -> stringlänge 1 (= eingegebenes Zeichen)+ 1 Nullzeichen(=\0)
Also das müsste eig. passen.Aber irgendwas passiert mit dem Pointer, während das scanf aufgerufen wird.
-
Hast Du keinen Debugger, mit dem Du Dir das anschauen kannst?
Dein Fall schreit geradezu danach.
-
Bjoernb schrieb:
Hm, also das "%1s" in Verbindung mit unsigned char dürfte meines Wissens nach keine Probleme verursachen...
Bedeutet ja eig. -> stringlänge 1 (= eingegebenes Zeichen)+ 1 Nullzeichen(=\0)
Also das müsste eig. passen.nein, das kann nicht passen. stringlänge 1 + 1 nullzeichen macht summa summarum zwei zeichen, aber nur eins passt in einen char bzw. unsigned char.
-
Mit %c als Format springt er sofort aus der Schleife, gibt aber die richtigen Werte aus.. d.h. also die Bedingung c=='j' ist schon nicht mehr erfüllt.
-
das rausspringen aus der schleife sieht mir nach dem typischen problem des nicht geleerten eingabepuffers aus. heißt also, du müsstest mal nach dem scanf den puffer leer machen.
-
Jop, so siehts aus:
scanf will leave the \n in the buffer for the next read ...
Mit Pufferentleerung funktionierts nun.
Danke für die Hilfe.
MfG
-
Kann man mit der extra anzugebenden Feldbreite (in diesem Fall 1) die Funktion gegen einen Pufferüberlauf zuverlässig absichern?
Dann verstehe ich nicht, warum immer alle so einen Wind darum machen, dass man alles mit dem ach so sicheren fgets einlesen sollte. Dass liest (nervigerweise) ja auch immer das newline-Zeichen mit ein.
-
Balu Jr. schrieb:
Kann man mit der extra anzugebenden Feldbreite (in diesem Fall 1) die Funktion gegen einen Pufferüberlauf zuverlässig absichern?
die angabe der feldbreite soll doch gerade vor einem überlauf schützen.
in diesem fall ist ein char array mit zwei elementen nötig. ein element für das einzulesende zeichen und ein element für die terminierung.Balu Jr. schrieb:
Dann verstehe ich nicht, warum immer alle so einen Wind darum machen, dass man alles mit dem ach so sicheren fgets einlesen sollte. Dass liest (nervigerweise) ja auch immer das newline-Zeichen mit ein.
wieso auch, scanf lässt das newline im puffer stehen. fgets liest ein newline ein, wenn noch platz im array ist, sonst nicht. aber auch hier gibt es wie auch bei scanf einen überlauf, wenn der puffer kleiner ist als angegeben.