sscanf() Verständnisproblem

Knaecke

Hallo allerseits,

ich hab mal wieder mit C zu tun und bin heute beim Anpassen einer Schnittstelle hier direkt über ein Problem mit sscanf() gestolpert. Ich hab zwar noch den Fehler gefunden, aber würd gern mal erklärt bekommen, wieso und warum das nun so funktioniert, komm da nicht dahinter.

Folgendes war mein fehlerhafter Code:

char bla[4], a[10], b[10], blub[10];

sscanf(STRING_A, "%3s_%9s_%8s_%4s%s", bla, a ,create_date, create_time, blub);
printf("a:\n", a);
sscanf(STRING_B, "%3s_%10s_%8s_%4s%s", bla, b ,create_date, create_time, blub);
printf("a:\n", a);
printf("b:\n", b);

Ausgabe:

EIN_IF017

EIN_IF017w

Nun in dieser Form der "kurzen" Zusammenfassung ist es schnell zu erkennen, dass ich oben bei b vergessen hab, ein Zeichen mehr zuzuordnen (das ist wirklich eins länger, siehe Ausgabe, die ist soweit richtig).

Ich raff ja noch, dass beim zweiten sscanf() das EKZ vom String b im Speicher bleibt. Aber anscheinend überschreibt das mein vorher eingelesenes a, so dass a plötzlich leer ist. Wie kann das denn sein?

Würd mich freuen, wenn mir das mal jemand nahe bringen könnte. Dankeschön.

PS: Die Lösung war natürlich, b als char b[11] zu deklarieren.

CStoll

Die Eingabe überschreibt nicht dein komplettes a. Aber offenbar steht a direkt hinter b auf dem Stack, so daß der Null-Terminator von b (der nicht mehr ins Array passt) das erste Element von a überschreibt - und deshalb sieht es so aus, als wäre a leer.

Knaecke

Ja klar

An den Speicher selbst hatte ich auch schon gedacht (irgendsowas musste es ja sein), aber so genau bin ich auch nicht drauf gekommen. Das klingt auf alle Fälle sehr plausibel und erklärt natürlich auch das spätere "Überschreiben". Ich bin wohl mittlerweile zu sehr von der automatischen Speicherverwaltung der anderen Sprachen verwöhnt, dass ich darüber gar nicht mehr soviel nachdenke...