Wie kommt es, dass char[3] mit mehr als 3 Zeichen angezeigt werden kann?

   char fromBluetooth[] = "zgr\r123\r";
   int name_length = 0;
    int pass_length = 0;

    while (1)
    {
        if (fromBluetooth[name_length] == '\r')
        {
            break;
        }name_length++;
    }

    char ssid_determined[name_length];

    for (int i = 0; i < name_length; i++)
    {
        ssid_determined[i] = fromBluetooth[i];
    }

    lcd.clear();
    lcd.setCursor(0,0);
    lcd.print(ssid_determined);

Dieser Code sollte auf dem LCD ein Ergebnis als "zgr" liefern, aber was ich auf dem LCD bekomme, ist "zgr!\r\r". Kann mir jemand erklären wie das geht?

HINWEIS: Dieses LCD-Objekt ist der LiquidCrystal-Typ von Arduino.

Sie müssen ssid_determined mit Null beenden. Andernfalls druckt es einfach weiter, bis es auf eine Speicheradresse mit dem Wert 0 trifft.

Antworten (1)

Zunächst einmal bin ich mir nicht sicher, wie Sie ein Array mit einer zur Laufzeit angegebenen Länge deklarieren. Das ist Standard-C, richtig?

Was wahrscheinlich Ihr Problem verursacht, ist, dass ssid_determined nicht nullterminiert ist. Die Größe von ssid_determined sollte name_length + 1 sein, und das letzte Zeichen sollte '\0' sein.

plus eins an der Null-Terminierung. Das ist das Problem. Arrays mit variabler Länge werden in ISO C99 eingeführt, Sie können sie also als Standard bezeichnen.
Sieht so aus, als wären VLAs in C11 optional: groups.google.com/forum/#!topic/comp.std.c/AoB6LFHcd88 . Scheint ein fragwürdiges Feature in einem eingebetteten Programm zu sein, aber vielleicht bin ich nur altmodisch.
Ich stimme zu, dass eingebettete dynamische Zuweisungen sogar auf dem Stapel besser zu vermeiden sind. Der Stapel ist normalerweise ziemlich flach, es ist leicht, ihn zu überlaufen.
@AdamHaun: Sie waren ein obligatorisches Feature in C99, aber da gcc sie erst um 2010 richtig gemacht hat, war es wahrscheinlich ein zu schwieriges Feature, um es von allen zu verlangen.
Die Ratsamkeit von Array-Typen mit variabler Länge (oder irgendetwas) im Grunde auf Embedded hängt immer noch etwas von der Qualität der zugrunde liegenden Compiler-Suite ab. In einigen Fällen auch die eigentliche Hardware. Wenn Sie dies auf einem mit Due-ähnlichen ARM ausgestatteten Board mit den richtigen und neuesten GCC-basierten Compilern ausführen, werden Sie nicht so viele Leistungsprobleme bemerken. Der eigentliche Ärger beginnt in diesem Fall, wenn Sie es dazu zwingen, Funktionen vom Typ malloc () zu verwenden, anstatt an etwas zu "denken", das für sich selbst passt. Zumindest nach meiner bescheidenen Erfahrung.