Verkettete Liste - merkwürdiger Fehler!
-
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.