Komische Werte im char array

[Andi (Gast)]

Hallo Leute!

Ich möchte aus einem gegebenen char-Array einen bestimmten Teil 
ausschneiden. Dazu suche ich mit einer for-Schleife nach einem 
Trennzeichen (in diesem Fall '.'). Der Inhalt vom Anfang des char-Arrays 
bis zu dem character vor dem Trennzeichen soll über eine weitere 
for-Schleife in einem neuen char-Array gespeichert werden.
Später soll dann mithilfe von atoi() der Inhalt des Arrays in eine 
integer-Zahl umgewandelt werden. Das funktioniert auch soweit.

Allerdings sehe ich beim Debuggen einen komischen Wert im char-Array der 
immer wieder auftaucht. Hier erstmal mein Code:

#define SERIAL_BUFFER_SIZE 10

int main(void) {
  const char data[SERIAL_BUFFER_SIZE] = {'1','2','3','4','5','6','.','7','8','\0'};
  uint8_t indexDot, length;

  for(uint8_t i = 0; i < SERIAL_BUFFER_SIZE; i++) {
    if (data[i] == '.') {
      indexDot = i;
    } else if (data[i] == '\0') {
      length = i + 1;
    }
  }

  char foo1[indexDot];
  memset(foo1,0,indexDot); //nullen
  for(uint8_t i = 0; i < indexDot; i++) {
    foo1[i] = data[i];
  }

  char foo2[SERIAL_BUFFER_SIZE-indexDot-2];
  memset(foo2,0,SERIAL_BUFFER_SIZE-indexDot-2); //nullen
  for(uint8_t i = 0; i < SERIAL_BUFFER_SIZE-indexDot-1; i++) {
        f002[i] = data[indexDot+1+i];
  }

  //Conversion to integer
  uint32_t integer_foo1 = atoi(foo1);
  uint32_t integer_foo2 = atoi(foo2);
}

Die erste for-Schleife findet die Länge des Arrays heraus (hier 
eigentlich unnötig, da sowieso fest) und die Stelle des Trennzeichens 
'.'.

Nachdem aber die zweite for-Schleife durchlaufen ist, wird im letzten 
Schleifendurchlauf immer noch ein '@' an die letzte Stelle hinzugefügt. 
D.h. ich erhalte dann "123456@". Bei der letzten for-Schleife 
funktioniert wieder alles bestens.

Weiß jemand woher dieses Zeichen kommt?

Eine weiter Frage: Ist das Nullen der Arrays mit memset() überhaupt 
nötig? Wie sieht das ganze bei µC aus?

Schon mal vielen Dank! :)

[Peter II (Gast)]

Andi schrieb:
> Weiß jemand woher dieses Zeichen kommt?

ja weil du keine ende vom String hast. Es fehlt ein 0 Byte.

Aber das ganze ist viel zu kompliziert!

das ganze umkopieren ist überhaupt nicht notwenig, atoi hört von selber 
auf zu lesen wenn kein Digit mehr kommt.

[Andi (Gast)]

Peter II schrieb:
> Andi schrieb:
>> Weiß jemand woher dieses Zeichen kommt?
>
> ja weil du keine ende vom String hast. Es fehlt ein 0 Byte.
>
> Aber das ganze ist viel zu kompliziert!
>
> das ganze umkopieren ist überhaupt nicht notwenig, atoi hört von selber
> auf zu lesen wenn kein Digit mehr kommt.

Warum ist dann beim Array foo2 nie so ein Zeichen am Ende?

Danke für den Hinweis mit atoi! Da kann ich mir die Hälfte sparen ;)

[Bitflüsterer (Gast)]

#include "string.h"

#define SERIAL_BUFFER_SIZE 10

int main(void) {
  char data[SERIAL_BUFFER_SIZE] = {'1','2','3','4','5','6','.','7','8','\0'};
  uint8_t indexDot;

  dot = strnchr (data, SERIAL_BUFFER_SIZE, '.');
  data [dot] = '\0';

  uint32_t integer_foo1 = atol(data);
  uint32_t integer_foo2 = atol(&data[dot + 1]);

Fehlerbehandlung fehlt natürlich noch.

[Bitflüsterer (Gast)]

Wobei atol natürlich auch ein wenig blöd ist, wenn Du den vollen 
Wertebereich von uint32_t nutzen willst. Aber gut. Das Ganze ist sowieso 
ein Blödsinn - äh, ein Übungscode zum wegschmeissen, da schadet das nun 
auch nichts.

[A. H. (ah8)]

An dieser Stelle sollte Dein Compiler laut meckern:

  char foo1[indexDot];

Wenn Du ein Feld definieren willst muss die Größe zur Compilezeit 
bekannt sein. indexDot ist aber eine Variable. Definiere das Feld auch 
zu SERIAL_BUFFER_SIZE und probiere es noch mal.

Die schon erwähnte Bemerkung mit dem fehlenden '\0' Zeichen stimmt 
natürlich auch. Du müsstest mindestens indexDot + 1 als Feldgröße 
anlegen.

[Andi (Gast)]

A. H. schrieb:
> An dieser Stelle sollte Dein Compiler laut meckern:
>   char foo1[indexDot];
>
> Wenn Du ein Feld definieren willst muss die Größe zur Compilezeit
> bekannt sein. indexDot ist aber eine Variable. Definiere das Feld auch
> zu SERIAL_BUFFER_SIZE und probiere es noch mal.
>
> Die schon erwähnte Bemerkung mit dem fehlenden '\0' Zeichen stimmt
> natürlich auch. Du müsstest mindestens indexDot + 1 als Feldgröße
> anlegen.

Der Compiler sagt dazu nichts...seltsam. Ich dachte die Terminierung mit 
dem '\0'-Zeichen wird nur für die Interpretation als String benötigt?

[Peter II (Gast)]

A. H. schrieb:
> An dieser Stelle sollte Dein Compiler laut meckern:
>   char foo1[indexDot];
>
> Wenn Du ein Feld definieren willst muss die Größe zur Compilezeit
> bekannt sein.

nein muss es nicht. Im Aktuellen C und C++ ist das zulässig.

[Peter II (Gast)]

Andi schrieb:
> Ich dachte die Terminierung mit
> dem '\0'-Zeichen wird nur für die Interpretation als String benötigt?

sie immer notwendig wenn man in C mit Strings arbeitet. Woher soll denn 
sonst atoi wissen wo schluss ist.

[Peter II (Gast)]

Bitflüsterer schrieb:
> #include "string.h"
>
> #define SERIAL_BUFFER_SIZE 10
>
> int main(void) {
>   char data[SERIAL_BUFFER_SIZE] =
> {'1','2','3','4','5','6','.','7','8','\0'};
>   uint8_t indexDot;
>
>   dot = strnchr (data, SERIAL_BUFFER_SIZE, '.');
>   data [dot] = '\0';
>
>   uint32_t integer_foo1 = atol(data);
>   uint32_t integer_foo2 = atol(&data[dot + 1]);
>
> Fehlerbehandlung fehlt natürlich noch.

data [dot] = '\0';

ist nicht notwendig, kann sogar stören. Wenn man mit const arbeitet.

[A. H. (ah8)]

Peter II schrieb:
> A. H. schrieb:
>> An dieser Stelle sollte Dein Compiler laut meckern:
>>   char foo1[indexDot];
>>
>> Wenn Du ein Feld definieren willst muss die Größe zur Compilezeit
>> bekannt sein.
>
> nein muss es nicht. Im Aktuellen C und C++ ist das zulässig.

OK, man lernt nie aus, meine Standards sagen alle noch etwas anderes. 
(Sind aber nicht mehr die neuesten :-) Obwohl ich mir nicht vorstellen 
kann, wie der Compiler das macht. Zumindest dürfte es ja im gleiche 
Stack-Frame keine weiteren Variablen dahinter mehr geben?!

Oder macht er daraus implizit Pointer, initialisert sie zur Laufzeit mit 
dem Stackpointer und schiebt den einfach entsprechend weiter?

[Dirk B. (dirkb2)]

A. H. schrieb:
> OK, man lernt nie aus, meine Standards sagen alle noch etwas anderes.
> (Sind aber nicht mehr die neuesten :-)

VLA (Variable Length Array) gibt es seit C99.

Also auch schon seit 15 Jahren.

[A. H. (ah8)]

Dirk B. schrieb:
> A. H. schrieb:
>> OK, man lernt nie aus, meine Standards sagen alle noch etwas anderes.
>> (Sind aber nicht mehr die neuesten :-)
>
> VLA (Variable Length Array) gibt es seit C99.
>
> Also auch schon seit 15 Jahren.

Der letzte Standard (C++), den ich hier habe ist von 2003. Angesichts 
der Zeit, die viele Compiler brauchen, um neue Features zuverlässig zu 
implementieren, erachte ich das für die meisten Fälle auch noch als 
ausreichend. (Da wird für die Deklaration eines Arrays auch noch ein 
konstanter Ausdruck verlangt. Wenn es auf die Portabilität des Codes 
ankommt würde ich in diesem Fall auch versuchen, mich darauf zu 
beschränken.)

[Kaj (Gast)]

Peter II schrieb:
> nein muss es nicht. Im Aktuellen C und C++ ist das zulässig.

#include <stdint.h>

int main(void)
{
  uint8_t i;
  uint8_t array[i];
  for(i = 0; i < 10; i++)
  {
    array[i] = 0;
  }
  return 0;
}

mit gcc 4.8.1, -Wall -Werror -pedantic -pedantic-errors -std=c++11 
compiliert gibt:

error: ISO C++ forbids variable length array 'array' [-Wvla]

Scheint also doch nicht ganz so zulässig zu sein.

Andi schrieb:
> Der Compiler sagt dazu nichts...seltsam.
Der compiler sagt da nur was zu wenn du mit -pedantic compilierst. Ohne 
-pedantic hält er schön die klappe.

Grüße

[Tom K. (ez81)]

Kaj schrieb:
> Scheint also doch nicht ganz so zulässig zu sein.

In C99 schon, in C++ bisher nur als gcc-Erweiterung:

"Variable-length automatic arrays are allowed in ISO C99, and as an 
extension GCC accepts them in C90 mode and in C++."

[Peter II (Gast)]

Kaj schrieb:
> mit gcc 4.8.1, -Wall -Werror -pedantic -pedantic-errors -std=c++11
> compiliert gibt:error: ISO C++ forbids variable length array 'array'
> [-Wvla]
> Scheint also doch nicht ganz so zulässig zu sein.

bei C geht es

-Wall -Werror -pedantic -pedantic-errors -std=c99

test.c:6:11: error: variable 'array' set but not used 
[-Werror=unused-but-set-variable]
   uint8_t array[i];

[Kaj (Gast)]

Peter II schrieb:
> bei C geht es
Ja, habs grad festgestellt, liegt an der stelle am c++ compiler :-/

Tom K. schrieb:
> in C++ bisher nur als gcc-Erweiterung
Danke für den hinweis

[Johann L. (gjlayde)]

Tom K. schrieb:
> Kaj schrieb:
>> Scheint also doch nicht ganz so zulässig zu sein.
>
> In C99 schon, in C++ bisher nur als gcc-Erweiterung:
>
> "Variable-length automatic arrays are allowed in ISO C99, and as an
> extension GCC accepts them in C90 mode and in C++."

Und um es noch komplizierter zu machen: In C11 ist das Feature nur noch 
optional.