¿Cómo es que char[3] se puede mostrar con más de 3 caracteres?

   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);

Este código debería dar un resultado en la pantalla LCD como "zgr", pero lo que obtengo en la pantalla LCD es "zgr!\r\r". ¿Alguien puede explicarme cómo sucede esto?

NOTA: Ese objeto lcd es del tipo LiquidCrystal de Arduino.

Debe anular la terminación de ssid_determinado. De lo contrario, seguirá imprimiendo cosas hasta que se encuentre con una dirección de memoria que sea 0.

Respuestas (1)

En primer lugar, no estoy seguro de cómo está declarando una matriz con una longitud especificada en tiempo de ejecución. Este es el estándar C, ¿verdad?

Lo que probablemente esté causando su problema es que ssid_determinad no está terminado en nulo. El tamaño de ssid_determinad debe ser name_length + 1, y el carácter final debe ser '\0'.

más uno en la terminación nula. Este es el problema. Las matrices de longitud variable se introducen en ISO C99, por lo que puede llamarlas estándar.
Parece que los VLA son opcionales en C11: groups.google.com/forum/#!topic/comp.std.c/AoB6LFHcd88 . Parece una característica cuestionable en un programa integrado, pero tal vez solo estoy siendo anticuado.
Estoy de acuerdo en que es mejor evitar las asignaciones dinámicas incrustadas incluso en la pila. La pila suele ser bastante poco profunda, es fácil desbordarla.
@AdamHaun: Han sido una característica obligatoria en C99, pero dado que gcc solo los acertó alrededor de 2010, probablemente fue una característica demasiado difícil de exigir de todos.
La conveniencia de los tipos de matrices de longitud variable (o cualquier cosa) básicamente en Embedded todavía depende en cierta medida de la calidad del conjunto de compiladores subyacente. Además, en algunos casos, el propio hardware. Si está ejecutando esto en una placa equipada con ARM de tipo due usando los compiladores basados ​​en GCC adecuados y más recientes, no notará tantos problemas de rendimiento. El problema real en ese caso comienza cuando lo fuerza a usar funciones de tipo malloc() en lugar de "pensar" en algo que se ajuste a sí mismo. En mi Humilde Experiencia, al menos.