Thorsten H. schrieb:
>
1 | > for (i = 0; (i < *radio.DataLen) && (i < MAX_LENGTH-1); i++)
|
2 | >
|
oder aber anstelle der Eigenbau-Schleife ganz einfach memcpy bzw. strcpy
benutzen.
Ich würde auch hier
1 | radio.Send(T_GATEWAYID, (uint8_t *)inData, strlen(inData), requestACK);
|
keinen strlen benutzen. Denn ich kenne ja die Länge des 'Strings'. Die
muss logischerweise *radio.DataLen sein.
Kein strlen -> keine Notwendigkeit, dass die Eingangswerte \0-terminiert
sind.
Die Funktion gibt dann einfach nur das weiter, was sie gekriegt hat. Was
immer das auch war.
Eine ganz andere Frage lautet: Warum muss das Array überhaupt umkopiert
werden? Würde ein
1 | radio.Send( T_GATEWAYID,
|
2 | (uint8_t *)radio.data,
|
3 | *radio.DataLen,
|
4 | requestACK);
|
nicht einfacher sein? Es kann jetzt natürlich sein, dass das radio
Objekt in den dazwischenliegenden Aufrufen den Datenbuffer löscht oder
aber das der Data Member kein Array von Bytes ist (halte ich aber eher
für unwahrscheinlich). In diesen Fällen müsste man natürlich umkopieren.
Und ja. Das *radio.Datalen sieht in der Tat merkwürdig aus. So ein
Konstrukt ist höchst ungewöhnlich. Es muss aber nicht notwendigerweise
falsch sein, wenn die Klasse des radio Obektes so etwas wie ein
Double-Buffering macht, um empfangene Daten für die Weiterverarbeitung
bereit zu stellen, während im Hintergrund der Empfang neuer Daten
bereits läuft.