Daten abfragen - scanf() macht Probleme
-
@DirkB sagte in Daten abfragen - scanf() macht Probleme:
Bei char-Arrays und %s gehört bei scanf kein & dazu.
Der Name des Arrays steht schon für dessen Anfangsadresse.Ne das&
passt schon. Es ist nur nicht nötig.
-
@hustbaer sagte in Daten abfragen - scanf() macht Probleme:
@DirkB sagte in Daten abfragen - scanf() macht Probleme:
Bei char-Arrays und %s gehört bei scanf kein & dazu.
Der Name des Arrays steht schon für dessen Anfangsadresse.Ne das
&
passt schon. Es ist nur nicht nötig.scanf erwartet bei %s einen Zeiger auf char,
Mit dem & ist es ein Zeiger auf ein char[20].Der Wert ist derselbe, der Typ ist anders.
Stur das & bei scanf zu benutzen, bringt dann in einer Funktion viel Freude.
-
@DirkB sagte in Daten abfragen - scanf() macht Probleme:
scanf erwartet bei %s einen Zeiger auf char,
Mit dem & ist es ein Zeiger auf ein char[20].Der Wert ist derselbe, der Typ ist anders.
OK. Du hast wohl Recht. In der Praxis macht es keinen Unterschied, aber streng genommen ist es vermutlich falsch.
Stur das & bei scanf zu benutzen, bringt dann in einer Funktion viel Freude.
Verstehe nicht was du damit sagen willst.
-
@hustbaer sagte in Daten abfragen - scanf() macht Probleme:
Stur das & bei scanf zu benutzen, bringt dann in einer Funktion viel Freude.
Verstehe nicht was du damit sagen willst.
Vermutlich so etwas:
void read(char str[]) { scanf("%s", &str); // Kabumm! }
-
@hustbaer sagte in Daten abfragen - scanf() macht Probleme:
OK. Du hast wohl Recht. In der Praxis macht es keinen Unterschied, aber streng genommen ist es vermutlich falsch.
char firstname[30]; scanf(" %s", &firstname);
Ist UB weil char** typinkompatibel zu char* ist (weil char* typinkompatibel zu char ist).
Korrekt ist alleinif( 1==scanf("%29[^\n]",firstname) ) ...
-
Wenn wir schon überkorrekt sind:
%[^\n]
macht was anderes als%s
.
-
@SeppJ
Dass mein Code was anders macht als der Originalcode war der Sinn meines Beitrages.
-
@Wutz sagte in Daten abfragen - scanf() macht Probleme:
Korrekt ist allein
if( 1==scanf("%29[^\n]",firstname) ) ...
„Günther Olaf von Wikingerstein“ gefällt das.
Das gibt zwar Probleme mit aufeinanderfolgenden Abfragen, aber die Lösung dazu wurde ja schon angesprochen.
-
Aber ihr könnt doch nicht wirklich das scanf für das Einlesen eines Strings ohne Längenangabe gut finden?! Und auch der Check auf Erfolg sollte doch immer dabei sein. Vielleicht ist es also keine so schlechte Idee, sich mal zu fragen, warum @Wutz das so geschrieben hat.
-
@wob sagte in Daten abfragen - scanf() macht Probleme:
Aber ihr könnt doch nicht wirklich das scanf für das Einlesen eines Strings ohne Längenangabe gut finden?! Und auch der Check auf Erfolg sollte doch immer dabei sein. Vielleicht ist es also keine so schlechte Idee, sich mal zu fragen, warum @Wutz das so geschrieben hat.
Das war nicht der Unterschied, den ich meinte. Ich bezog mich auf das unterschiedliche Verhalten bei Whitespace, worüber man nachdenken sollte, was man genau will. Längenangaben können die Stringformatspezifizierer ja alle.
-
@Wutz sagte in Daten abfragen - scanf() macht Probleme:
@hustbaer sagte in Daten abfragen - scanf() macht Probleme:
OK. Du hast wohl Recht. In der Praxis macht es keinen Unterschied, aber streng genommen ist es vermutlich falsch.
char firstname[30]; scanf(" %s", &firstname);
Ist UB weil char** typinkompatibel zu char* ist (weil char* typinkompatibel zu char ist).
Hm. Ich wüsste nicht was das mit
char**
zu tun hat.&firstname
ist die Adresse des Arrays, die gleich der Adresse des ersten Elements des Arrays ist. In C++ wäre der Typchar(*)[30]
. In C kenne ich mich diesbezüglich zu wenig aus, daher habe ich "wohl"/"vermutlich" geschrieben. Scheint aber nicht wirklich anders zu sein:int main(void) { char arr[30]; char* p = &arr; }
mit GCC 12 als C kompiliert:
<source>:3:15: warning: initialization of 'char *' from incompatible pointer type 'char (*)[30]' [-Wincompatible-pointer-types] 3 | char* p = &arr; | ^
Also ja, es ist UB. Weil
char *
nicht mitchar (*)[30]
kompatibel ist.char**
wäre nur im Spiel wennfirstname
ein Parameter wäre.