fgets wartet nicht, setzen einer variablen in einem struct lässt programm abstürzen

[Johannes (Gast)]

Hallo,
ich versuche in C eine Liste zu erstellen, hier habe ich aber zwei 
Probleme

struct liste
{
    uint8_t number;
    char word[20];
    struct liste *next;
};


static void eingabe(void)
{
    uint8_t number_u8;
    char word[20];
    printf("number.....................:");
    scanf("%3d", &number_u8);
    printf("word.......................:");
    fgets(word, 20, stdin);
    anhaengen(number_u8, word);
}

static void anhaengen(uint8_t number, char* n)
{
    printf("\nadd input in list %u %c\n", number, n);
    struct liste *pointer;

    if(NULL == list)
    {
        printf("empty list, create first element\n");
        if(NULL == malloc(sizeof(struct liste)))
        {
            fprintf(stderr, "no free memory\n");
            return;
        }

        printf("add list number\n");
        list->number = number;
        printf("add list word\n");
        strcpy(list->word, n);
        printf("add list next\n");
        list->next = NULL;
        printf("next element created\n");
    }

Das erste Problem ist, dass bei fgets nicht gewartet wird, bis ich eine 
Eingabe gemacht habe.
und beim setzen von number in die liste stürzt das Programm ab.

Der Output sieht wie folgt aus:

H:\Projects\C\liste>main
number.....................:2
word.......................:
add input in list 2 Ù
empty list, create first element
add list number

H:\Projects\C\liste>

1) wieso wartet fgets nicht bis ich die Daten schicke?
2) wieso stürzt list->number = number; ab?

[Nop (Gast)]

Johannes schrieb:

>     scanf("%3d", &number_u8);

Scanf erwartet dort einen Pointer auf einen Integer - es ist aber nur 
ein Pointer auf ein Byte.

>     fgets(word, 20, stdin);

word ist ein Buffer von 20 Zeichen, und Du liest 20 Zeichen ein - das 
ergibt u.U. einen String, der nicht nullterminiert ist. Mach den Buffer 
21 Zeichen groß und setz nach dem fgets noch:
word[20] = '\0';

>         if(NULL == malloc(sizeof(struct liste)))

Wo speicherst Du denn den Rückgabewert von malloc? Gar nicht.

[Nop (Gast)]

Übrigens hättest Du einiges davon schon gefunden, wenn Du mit -Wall 
-Wextra kompiliert hättest. Deswegen macht man das, damit man solche 
Fehler nicht selber suchen muß, sondern das den Compiler machen läßt.

[Dirk B. (dirkb2)]

Johannes schrieb:
> 1) wieso wartet fgets nicht bis ich die Daten schicke?

Weil im Eingabestrom noch das '\n' vom scanf ist.

> 2) wieso stürzt list->number = number; ab?

Weil list immer noch NULL ist.

fgets weiß um den Platz mit dem '\0' und berücksichtigt das.
fgets speichert das '\n' übrigens mit ab.

[123 (Gast)]

Johannes schrieb:
> Das erste Problem ist, dass bei fgets nicht gewartet wird, bis ich eine
> Eingabe gemacht habe.

weil dort bereits ein  '\n'-Zeichen (von der Zahleingabe) im Buffer ist.

Du musst stdin-Buffer leeren:

   printf("number.....................:");
    scanf("%3d", &number_u8);
    
    //Buffer leeren
    while (getchar() != '\n'){  
       //nothing to do
    }

    printf("word.......................:");
    fgets(word, 20, stdin);

Und die Sache mit malloc sollte auch verbessert werden

[123 (Gast)]

Nop schrieb:
> word ist ein Buffer von 20 Zeichen, und Du liest 20 Zeichen ein - das
> ergibt u.U. einen String, der nicht nullterminiert ist.

fgets schließt die Strings immer richtig (mit '\0') ab.

Die Frage ist nur, ob das Zeichen '\n' mitabgespeichert wird oder nicht. 
Bei einem Eingabestring >=20 Zeichen wird '\n' nicht mitgespeichert.

[Gerald K. (geku)]

Ich würde scanf und fgets nicht mischen.

Entweder beide Parameter nur mit scanf oder nur mit fgets  einlesen.

[Nop (Gast)]

Dirk B. schrieb:

> fgets weiß um den Platz mit dem '\0' und berücksichtigt das.
> fgets speichert das '\n' übrigens mit ab.

Stimmt. Das Problem, was ich meinte, hat strncpy, nicht fgets.

[Gerald K. (geku)]

Gerald K. schrieb:
> Ich würde scanf und fgets nicht mischen
Hilfreich wäre ein fehlerfrei kompilierbarer Code im Anhang gewesen.
Das im Text eingebettete Beispiel enthält viele Fehler. Ich habe es mit 
org.c nachgeholt.

In diesem Beispiel habe ich scanf durch fgets ersetzt.


Original (org.c):

static void eingabe(void)
{
 uint8_t number_u8;
 char word[20];
 printf("number.....................:");
 scanf("%3d", &number_u8);
 printf("word.......................:");
 fgets(word, 20, stdin);
 anhaengen(number_u8, word);
}

Nur mit fputs (test.c):

static void eingabe(void)
{
 uint8_t number_u8;
 char word[20];
 char number_str[4];

 printf("number.....................:");
 fgets(number_str,3,stdin);
 number_u8 = atoi(number_str) & 0xff;
 printf("word.......................:");
 fgets(word, 20, stdin);
 anhaengen(number_u8, word);
}

Das Programm sollte noch mit einem Eingabecheck versehen werden.

Scanf sollte man auf kleinen embedded Plattformen vermeiden, da sie viel 
Code produzieren.

Johannes schrieb:
> wieso stürzt list->number = number; ab?

Wo ist list deklariert?

liste wäre falsch, da es sich hier um den Datentyp handelt, richtig 
ist die Variable pointer mit dem Datentyp liste .

[Rolf M. (rmagnus)]

Nop schrieb:
> Johannes schrieb:
>
>>     scanf("%3d", &number_u8);
>
> Scanf erwartet dort einen Pointer auf einen Integer - es ist aber nur
> ein Pointer auf ein Byte.

Ja. Zur Erklärung: Man ist es von printf gewöhnt, dass man für alles, 
was kleiner als int ist, auch %d verwenden kann, auf Grund der Integer 
Promotion. Das gilt für scanf aber nicht, da dort kein Integer-Wert, 
sondern ein Zeiger übergeben wird. Dort kann so etwas natürlich nicht 
stattfinden, daher muss man hier immer den exakten Typ angeben. Im 
obigen Code schreibt scanf in Bytes, die nicht zu number_u8 gehören und 
macht damit vermutlich andere Daten kaputt.

Dirk B. schrieb:
>> 2) wieso stürzt list->number = number; ab?
>
> Weil list immer noch NULL ist.

Dem gezeigten Code fehlt die Definition von list, daher ist unbekannt, 
ob das wirklich NULL ist.

Johannes schrieb:
> static void anhaengen(uint8_t number, char* n)
> {
>     printf("\nadd input in list %u %c\n", number, n);

%c ist hier falsch. Das erwartet einen int, in dem ein Zeichen steht. Du 
übergibst aber stattdessen einen Zeiger. Deshalb kommt diese Ausgabe:

> add input in list 2 Ù

Es müsste hier %s heißen.

Gerald K. schrieb:
> Johannes schrieb:
>> wieso stürzt list->number = number; ab?
>
> Wo ist list deklariert?
>
> liste wäre falsch, da es sich hier um den Datentyp handelt, richtig
> ist die Variable pointer mit dem Datentyp liste .

pointer ist vom Datentyp Zeiger auf liste und wird hier nicht verwendet. 
Die Vermutung liegt nahe, dass list eine globale Variable ist, die hier 
im Posting vergessen wurde.

[Gerald K. (geku)]

Rolf M. schrieb:
> Die Vermutung liegt nahe, dass list eine globale Variable ist, die hier
> im Posting vergessen wurde.

Darum sollte man im Posting immer das komplette, lauffähige Beispiel im 
Anhang mitliefern.

Da man in der Liste nicht RÜCKWÄRTS suchen kann, ist eine Variable mit 
dem Zeiger auf das erste Listenelement notwendig. Globale oder static 
Variable.

[Dirk B. (dirkb2)]

Rolf M. schrieb:
> Dirk B. schrieb:
>>> 2) wieso stürzt list->number = number; ab?
>>
>> Weil list immer noch NULL ist.
>
> Dem gezeigten Code fehlt die Definition von list, daher ist unbekannt,
> ob das wirklich NULL ist.

In dem gezeigten Code-Schnippsel findet die Zuweisung an list->number 
nur statt, wenn NULL == list ist

[Dirk B. (dirkb2)]

@ Johannes (Gast)

Was möchtest du mit dem fgets einlesen?

Ein Wort, wie es der Variablenname suggeriert - dann ist fgets dafür 
nicht geeignet, sonder scanf mit "%19s"

Mehrere Wörter, die durch Leerzeichen getrennt werden - auch dafür hat 
scanf einen Formatspecifier: " %19[^\n]" (beachte das Leerzeichen vor 
dem %)

[Gerald K. (geku)]

Dirk B. schrieb:
> In dem gezeigten Code-Schnippsel findet die Zuweisung an list->number
> nur statt, wenn NULL == list ist

Vermutlich sollte mit malloc ein Wert zugewiesen werden.
Aber es ist richtig, dies funktioniert nur, wenn list vorher NULL war.
Mangels Code wissen wir es nicht.

[Dirk B. (dirkb2)]

Gerald K. schrieb:
> Vermutlich sollte mit malloc ein Wert zugewiesen werden.

Das wäre doch sehr sinnvoll.
Wenn man es nicht macht, entsteht auch ein Speicherleck.

Hätte man den Code auf zwei Zeilen gepackt, wäre das nicht passiert.
(ich meine hier Zuweisung an list und dann Überprüfung mit if in einer 
neuen Zeile).
Und hier (da list == NULL) braucht man auch keinen Hilfspointer, falls 
malloc NULL liefert.