Forum: Mikrocontroller und Digitale Elektronik [c] atoi mit 2d-Array bei uC

Hallo,

kontrolliere das Programm auch auf Bereichsüberschreitungen / 
Buffer-Overflows. Nicht das im RAM im Nirwana gelesen bzw. geschrieben 
wird.

foobar schrieb:
> Solange die \0 da ist, kein Problem.

Ich würde da auch mal in die atoi-Source schauen, ob das nicht auch bei 
unzulässigen Zeichen abbricht (was es eigentlich tun sollte). Die 
Chance, daß das dann trotz fehlender /0 niemals zurückkehrt, ist dann 
doch sehr gering.

Und ich würde mal nach Strings der Länge 8 bzw. einer Begrenzung auf 8 
Zeichen suchen...

Oliver

Tobi schrieb:
> Wie liegt ein 2d-Array genau im Speicher?

Die liegen hintereinander im Speicher (zumindest wenn es static ist):
int array1[3][2] = {{0, 1}, {2, 3}, {4, 5}};
Speicher -> 0 1 2 3 4 5

Tobi schrieb:
> Kann/Darf man z.B. atoi über eine Reihe laufen lassen (Terminiert mit
> 0)?

Wie bereits gesagt ist das kein Problem, solange die 0 wirklich da ist. 
Je nachdem wo das her komm ist das aber nicht unbedingt robust. Beim 
Empfangen kann ja auch mal etwas schief gehen.

Persönlich bevorzuge ich immer die Längenlimitierten String Funktionen 
wie z.B. strncmp statt strcmp. Ob es sowas für atoi gibt, weiß ich 
gerade nicht.

PS: Ich meine mich zu erinnern das atoi bei Zahlen, die zu groß sind, 
undefiniertes verhalten aufweist, vielleicht hat da ja noch wer anders 
Infos zu.

Kevin M. schrieb:
> Wie bereits gesagt ist das kein Problem, solange die 0 wirklich da ist.
> Je nachdem wo das her komm ist das aber nicht unbedingt robust. Beim
> Empfangen kann ja auch mal etwas schief gehen.

Wenn die /0 fehlt, wird atoi aber über nicht wandelbare Zeichen 
stolpern, und dann (hoffentlich) 0 zurückgeben. Der Fall wird ja 
(hoffentlich) abgefangen.

Ich würde aber auch mal schauen, ob da die Länge des Input-String 
begrenzt wird (und das auf weniger als 8 Zeichen ;) )

Alles in allem stirbt die Hoffnung, wie immer, zuletzt.

Oliver

atoi() erwartet ein NTBS, das kannst Du erzwingen (sicherstellen), indem 
Du ucInputData[...][7] = `\0` setzt (`\0` ist das Sentinel, was bei NTBS 
erwartet wird).

Besser wäre natürlich ein

1

std::array<std::array<char, 8>, 10> ucInputData;

und ein

1

template<auto N>

2

int atoi(const std::array<char, N>&);

Ansonsten hat atoi() das große Problem, das atoi() `0` liefert, wenn es 
die Zeichenkette nicht parsen kann. Man kann also ein gültiges nicht von 
einem ungültigen Ergebnis unterscheiden. Das ist broken-by-design.

Besser wäre natürlich

1

template<auto N>

2

std::optional<int> atoi(const std::array<char, N>&);

Tobi schrieb:
> Es gibt z.B. auf [0][0] ein Nullbyte. Alle zwei
> fortlaufenden Bytes [0][1], [0][2]... ist dieses auch zu sehen.
> So kann das mit atoi ja nicht klappen.
>
> ...Nur warum ab und an bei verschiedenen Controllern...
> Verrückt (RAM kaputt?)

Big- und Little-Endian Problem?

Wiviel Dezimalstellen hat denn die Zahl?

Oliver S. schrieb:
> Wenn die /0 fehlt, wird atoi aber über nicht wandelbare Zeichen
> stolpern, und dann (hoffentlich) 0 zurückgeben. Der Fall wird ja
> (hoffentlich) abgefangen.

Nein. Dann hört atoi() einfach auf und gibt den bereits ermittelten Wert 
zurück. Bei "8ung" wäre das 8.

Tobi schrieb:
> Ich habe noch etwas entdeckt nachdem ich jedes Byte des Arrays
> ausgegeben habe. Es gibt z.B. auf [0][0] ein Nullbyte. Alle zwei
> fortlaufenden Bytes [0][1], [0][2]... ist dieses auch zu sehen.
> So kann das mit atoi ja nicht klappen.

Wo kommen denn die Daten her?

Tobi schrieb:
> Ich habe das Problem-Array einmal gefüllt und ausgelesen.
> Bei dem funktionierenden Controller kommen die korrekten Bytes zurück
> (wenn auch meine for/next irgendwo noch patzt :) ).

Denke nicht: sollte ja mit 0 beginnen.

Tobi schrieb:
> Wilhelm M. schrieb:
>> Tobi schrieb:
>>> Ich habe noch etwas entdeckt nachdem ich jedes Byte des Arrays
>>> ausgegeben habe. Es gibt z.B. auf [0][0] ein Nullbyte. Alle zwei
>>> fortlaufenden Bytes [0][1], [0][2]... ist dieses auch zu sehen.
>>> So kann das mit atoi ja nicht klappen.
>> Wo kommen denn die Daten her?
> Von der UART und externen Programm.

Ok, aber das ist ja für den obigen Test irrelevant.

Tobi schrieb:
> (wenn auch meine for/next irgendwo noch patzt :) ).

Was soll das sein?

C99 liegt schon 23 Jahre zurück, also der alte Code und v.a. Dein 
Testprogramm sollte dann schon etwas moderner sein (Stichwort: 
Gültigkeitsbereich der Variablen).

Wilhelm M. schrieb:
> Was soll das sein?
>
> C99 liegt schon 23 Jahre zurück, also der alte Code und v.a. Dein
> Testprogramm sollte dann schon etwas moderner sein

Die Aussage ist doch Quatsch. Wie der Themenersteller schon erwähnte, 
wurde der originale Sourcecode vor 15 Jahren geschrieben. Damals war C99 
sehr wohl der Stand der Technik.

Mark B. schrieb:
> Wilhelm M. schrieb:
>> Was soll das sein?
>>
>> C99 liegt schon 23 Jahre zurück, also der alte Code und v.a. Dein
>> Testprogramm sollte dann schon etwas moderner sein
>
> Die Aussage ist doch Quatsch. Wie der Themenersteller schon erwähnte,
> wurde der originale Sourcecode vor 15 Jahren geschrieben. Damals war C99
> sehr wohl der Stand der Technik.

Genau!
Du hast meine Aussage so gar nicht verstanden ...

Tobi im Feierabend :) schrieb:
> Wilhelm M. schrieb:
>>> Ich habe das Problem-Array einmal gefüllt und ausgelesen.
>>> Bei dem funktionierenden Controller kommen die korrekten Bytes zurück
>>> (wenn auch meine for/next irgendwo noch patzt :) ).
>> Denke nicht: sollte ja mit 0 beginnen.
> Ja, theoretisch schon.
> Ist aber Quick n dirty programmiert ohne zu checken ob ich das richtig
> gemacht habe ;)

Wie so oft, hast Du mal wieder nicht alles gezeigt!
Ich ging davon aus, dass das der Inhalt von main() ist. Wenn das so ist, 
dann ist das von Dir gezeigte Ergebnis eben nicht OK.

Tobi im Feierabend :) schrieb:
> Wilhelm M. schrieb:
>> C99 liegt schon 23 Jahre zurück, also der alte Code und v.a. Dein
>> Testprogramm sollte dann schon etwas moderner sein (Stichwort:
>> Gültigkeitsbereich der Variablen).
> Mein Testprogramm ist ein Debug-Teil des kompletten Programmes und auch
> in der alten WinXP-IDE geschrieben.
> Da ändert sich also nichts.

Warum schreibst Du auch Deinen Test-Code so grottig wie der 
ursprüngliche Autor? Das zeugt nicht unbedingt von Kompetenz.

Tobi im Feierabend :) schrieb:
> Also bitte nicht so unnötig dazwischen quatschen.

Halte mal den Ball flach!

Tobi im Feierabend :) schrieb:
> Wilhelm M. schrieb:
>> Wie so oft, hast Du mal wieder nicht alles gezeigt!
>> Ich ging davon aus, dass das der Inhalt von main() ist. Wenn das so ist,
>> dann ist das von Dir gezeigte Ergebnis eben nicht OK.
> Wie so oft? Wie kommst Du darauf?

Standard in diesem Forum.

> Es ist mein Testcode am Anfang der Main.
> Das Programm selbst hat ca. 5000 LOC.
> Aber das ist ja auch nicht relevant, wenn man in dem kurzen Code snipped
> schon sieht, dass was gravierend nicht passt.

Was hier nicht passt, ist:

1

unsigned char ucInputData[10][8];

Hier haben wir also 180 Bytes (auf dem Stack oder global, kann ich nicht 
entscheiden, weil Du mal wieder nicht alles zeigst).


Und im folgenden Snippet schreibst Du gnadenlose über das Ende des 
Arrays hinaus. Also, was sollen wir davon halten, wenn solche Basics 
nicht passen. Dann wird wohl auch an anderer Stelle was gravierend faul 
sein.

1

unsigned int i;

2

unsigned char *pointbase;

3

unsigned char *pointa;

4

pointbase = &ucInputData[0][0];    //Pointer von Array start speichern

5

//32+4 * 8 -> 288bytes

6

for(i=0;i<250;i++)          

7

{

8

  pointa = pointbase + i;

9

  *pointa=i;            //RAM-Speicherstellen setzen 0-250

10

}        

11

for(i=0;i<250;i++)

12

{

13

  pointa = pointbase + i;

14

  uart_0_put_uart_mode(*pointa);  //RAM-Speicherstellen wieder zurück lesen und via UART ausgeben

15

} 

16

while(1);

Tobi im Feierabend :) schrieb:
> Vor allem, wo soll das kleine Ding denn grottig sein?

Ich hatte Dir oben einen Hinweis gegeben, den Du ggf. übersehen oder 
nicht verstanden hast.

Tobi im Feierabend :) schrieb:
> Wilhelm M. schrieb:
>> Halte mal den Ball flach!
> Du hast schon gesehen, dass der Kommentar nicht an Dich ging oder?

Natürlich, und trotzdem schreibe ich was dazu. Es ist ein Forum und 
keine P2P-Kommunikation.

Tobi im Feierabend :) schrieb:
> Wilhelm M. schrieb:
>>> Aber das ist ja auch nicht relevant, wenn man in dem kurzen Code snipped
>>> schon sieht, dass was gravierend nicht passt.
>> Was hier nicht passt, ist:
>> unsigned char ucInputData[10][8];
>>
>> Hier haben wir also 180 Bytes (auf dem Stack oder global, kann ich nicht
>> entscheiden, weil Du mal wieder nicht alles zeigst).
> Ja, da hast Du recht.
> Das habe ich nicht erwähnt.
> Die 10/8 Bytes waren anfangs geschätzt, da über mehrere Defines
> deklariert und es zu dem Zeitpunkt auch nur um das atoi() ging.
> Das hatte ich bei meinem Testcode dann jedoch nachgeschaut und meine
> Notiz "//32+4 * 8 -> 288bytes" hinzugefügt.

Kommentare sind irrelevant, da keine überprüfbare Verknüpfung zum Code 
besteht.

> Sorry.

Kein Thema.

Tobi im Feierabend :) schrieb:
> Wilhelm M. schrieb:
>> Tobi im Feierabend :) schrieb:
>>> Vor allem, wo soll das kleine Ding denn grottig sein?
>>
>> Ich hatte Dir oben einen Hinweis gegeben, den Du ggf. übersehen oder
>> nicht verstanden hast.
> Scheinbar habe ich das.
> Welchen genau meintest Du?

Z.B. Lokalität / Gültigkeitsbereich von Variablen, ...

Wilhelm M. schrieb:
> Ansonsten hat atoi() das große Problem, das atoi() `0` liefert, wenn es
> die Zeichenkette nicht parsen kann. Man kann also ein gültiges nicht von
> einem ungültigen Ergebnis unterscheiden. Das ist broken-by-design.

Ich benutze daher sscanf(), das liefert die Anzahl der fehlerfrei 
gelesenen Werte zurück.

Peter D. schrieb:
> Wilhelm M. schrieb:
>> Ansonsten hat atoi() das große Problem, das atoi() `0` liefert, wenn es
>> die Zeichenkette nicht parsen kann. Man kann also ein gültiges nicht von
>> einem ungültigen Ergebnis unterscheiden. Das ist broken-by-design.
>
> Ich benutze daher sscanf(), das liefert die Anzahl der fehlerfrei
> gelesenen Werte zurück.

Das sind doch alles Krücken, die zuviel Aufwand verursachen (bei 
sscanf() in der Tat nur, wenn man >1 Format-Spezifizierer hat).

Wesentlich besser ist da

https://en.cppreference.com/w/cpp/utility/from_chars

was man auch gut verketten kann (oder man nutzt - wie oben schon 
geschrieben - std::optional<>, falls man Output-Parameter vermeiden 
möchte).

Wilhelm M. schrieb:
> std::

Wie häufig sind deine Ratschläge zwar prinzipiell richtig, helfen aber 
einem C-Programmierer nicht wirklich weiter. Und sehr vermutlich wird es 
auch hier um C gehen.

Oliver

Oliver S. schrieb:
> Wilhelm M. schrieb:
>> std::
>
> Wie häufig sind deine Ratschläge zwar prinzipiell richtig, helfen aber
> einem C-Programmierer nicht wirklich weiter. Und sehr vermutlich wird es
> auch hier um C gehen.

Naja, dass es um C geht, das steht ja schon in der Überschrift ;-)

Und wie immer erlaube ich mir den Blick etwas zu weiten.

Und eine C-Lib-Funktion wie `int atoi()` gehört einfach auf den Orkus 
der Geschichte: den Wert `0`, der zum gültigen Wertebereich eines `int` 
gehört, als Fehlerindikator zu verwenden, ist einfach nur Quatsch 
(wohlwissend, dass man natürlich zunächst prüfen kann, ob der String 
sicher aus `[+-0-9]` zusammensetzt).

Peter D. schrieb:
> Wilhelm M. schrieb:
>> Ansonsten hat atoi() das große Problem, das atoi() `0` liefert, wenn es
>> die Zeichenkette nicht parsen kann. Man kann also ein gültiges nicht von
>> einem ungültigen Ergebnis unterscheiden. Das ist broken-by-design.
>
> Ich benutze daher sscanf(), das liefert die Anzahl der fehlerfrei
> gelesenen Werte zurück.

Als Ersatz für atoi gibt es strtol.
Das benutzt auch errno und liefert auch die Position, an der die 
Umwandlung stoppt.

Dirk B. schrieb:
> Peter D. schrieb:
>> Wilhelm M. schrieb:
>>> Ansonsten hat atoi() das große Problem, das atoi() `0` liefert, wenn es
>>> die Zeichenkette nicht parsen kann. Man kann also ein gültiges nicht von
>>> einem ungültigen Ergebnis unterscheiden. Das ist broken-by-design.
>>
>> Ich benutze daher sscanf(), das liefert die Anzahl der fehlerfrei
>> gelesenen Werte zurück.
>
> Als Ersatz für atoi gibt es strtol.
> Das benutzt auch errno und liefert auch die Position, an der die
> Umwandlung stoppt.

Stimmt nicht ganz:

- error wir benutzt, wenn ein range-error auftritt (C99 konform)
- bei anderen Fehlern wie nach wie vor `0` zurück gegeben.

Nur bei nicht C99-konformen Implementierungen wird errno == EINVAL 
gesetzt:

https://en.cppreference.com/w/c/string/byte/strtol

https://man7.org/linux/man-pages/man3/strtol.3.html

Wilhelm M. schrieb:
>> Als Ersatz für atoi gibt es strtol.
>> Das benutzt auch errno und liefert auch die Position, an der die
>> Umwandlung stoppt.
>
> Stimmt nicht ganz:
>
> - error wir benutzt, wenn ein range-error auftritt (C99 konform)
> - bei anderen Fehlern wie nach wie vor `0` zurück gegeben.

Und:

If there were no digits at all,
strtol() stores the original value of nptr in *endptr (and
returns 0).  In particular, if *nptr is not '\0' but **endptr is
'\0' on return, the entire string is valid.

> https://man7.org/linux/man-pages/man3/strtol.3.html

Da gibt es auch ein Beispiel.