was macht itoa

google schon wieder kaputt?

lmgtfy
http://www.cplusplus.com/reference/cstdlib/itoa/

Der Parameter str, sagt der Funktion itoa, wo im Speicher es den von ihr 
erzeugten String von Ziffern ablegen soll.

Das scheint auf den ersten Blick redundant, da ja itoa als Rückgabewert, 
genau diesen Zeiger zurückgibt.

Es gibt dafür mehrere Argumente, von denen nicht alle zwingend sind.
Nur ein Beispiel:
Oft ist es so, dass Ausgabebuffer ohnehin mehrere verschiedene Daten aus 
verschiedenen Verarbeitungsschritten beinhalten. In dem man den Zeiger 
übergibt, erspart man sich z.B. das spätere Umkopieren des Ergebnisses 
und den zusätzlichen Speicher. Das trifft in Deiner Anwendung zwar nicht 
zu, aber die Funktion kann so auch für den anderen Fall verwendet 
werden.

https://de.wikipedia.org/wiki/Islands_on_the_Air

Teo D. schrieb:

1

  if(val < 0) {

2

    *buf++ = '-';

3

    val = -val;

4

  }

Dazu wäre noch anzumerken, daß diese Routine scheitert für den Wert 
INT_MIN, der nämlich keinen positiven Gegenwert hat. Sofern man diesen 
Wert niemals hat, ist die Funktion OK, aber für eine generische 
Library-Funktion sollte da ein expliziter Check drinstehen.

Danke c.m. für den link(englischsprachige Ergebnisse sind halt wenn man 
noch am anfang ist teilweise schwer zu verstehen), Theor und den anderen 
für die Antworten.

Teo D. schrieb:
> ???

Guck Dir mal die Wertebereiche von Integern an. Im Falle von z.B. 16 bit 
gehen die von -32768 bis 32767. +32768 ist nicht darstellbar. Also was 
passiert, wenn man der Routine -32768 übergibt und sie versucht, das 
Vorzeichen zu wechseln?

> PS: Das ist der original Code von xc8 (gcc Clone).

Der Code ist halt an der Stelle fehlerhaft.

Nop schrieb:
> Guck Dir mal die Wertebereiche von Integern an. Im Falle von z.B. 16 bit
> gehen die von -32768 bis 32767. +32768 ist nicht darstellbar. Also was
> passiert, wenn man der Routine -32768 übergibt und sie versucht, das
> Vorzeichen zu wechseln?

Naja doch, eigentlich würde das gehen.

Aus -32768 ($8000) wird wieder -32768($8000). Das wird in utoa auf ein 
unsigned int gecastet und wird damit zu 32768, welches korrekt im 
Wertebereich bis 65536 liegt.

Dumm nur, wenn der Compiler das automatisch an den Wertebereich der CPU 
anpasst und aus dem $8000 bei Übergabe ein $FFFF8000 wird.

Gottaquest schrieb:
> Danke c.m. für den link(englischsprachige Ergebnisse sind halt
> wenn man
> noch am anfang ist teilweise schwer zu verstehen), ...

gute englischkenntnisse sind vorauszusetzen. 2018 und so.

Nop schrieb:
> Dazu wäre noch anzumerken, daß diese Routine scheitert für den Wert
> INT_MIN, der nämlich keinen positiven Gegenwert hat.

Das steht doch im Kontext zum utoa - Aufruf. Bei 
2er-komplement-maschinen gibt's ja keinen Fehler. Bei den mit Vorzeichen 
auch nicht.

Wo schlägt sowas in der Praxis fehl? Also auf welchen Architekturen?

Carl D. schrieb:
> Java z.B.
> verzichtet auf unsigned und braucht dann eben immer die nächstgrössere
> Integer-Variante.

Da wirds aber lustig, wenn ich einen 64bit-Integer durch 10 teilen will, 
um ihn in Dezimalstellen zu zerlegen.

Sämtliche mir bekannten - ok, ich kenne sicher nicht alle - 
Ganzzahl-Divisionen erledigen signed Division dadurch, dass sie die 
negativen Zahlen negieren und dann eine unsigned Division durchführen.

Karl schrieb:

> Aus -32768 ($8000) wird wieder -32768($8000).

Das ist signed integer overflow und damit undefined behaviour.


Carl D. schrieb:
> Wenn [unsigned] int 32 Bit lang ist, dann existiert das Problem für
> -32768 gar nicht.

Dann existiert es in derselben Form aber für INT_MIN/32.


Achim S. schrieb:
> Wo schlägt sowas in der Praxis fehl? Also auf welchen Architekturen?

Undefined behaviour kann einen nach jedem Compiler-Update beißen. Auf 
jeder Architektur. Das ist umso schlimmer, wenn es vorher lief und sich 
um eigentlich reifgetesteten Code handelt.

Nop schrieb:
> Das ist signed integer overflow und damit undefined behaviour.

Ja stimmt, aber andererseits: Für 99.999% der Fälle irrelevant. Denn 
wenn ich reale Werte speichere, wird ein Integer seltenst komplett 
ausgereizt.

Dafür schleppe ich dann für den unwahrscheinlichen Fall, dass jemand 
wirklich mal mit einem Wert von -32,768m rechnet und den in ein unsigned 
Int packt immer die Prüfabfrage mit rum.

Mein Compiler mahnt auch immer an: int16 = uint16 + int16 könnte den 
Wertebereich überschreiben. Da ich weiss, dass die Werte reinpassen 
juckt mich das nicht.

Das ist bei Ada schön, da kann man festlegen: Die Zahl kommt nur 
zwischen -4000 und 12000 vor, und schon weiss der Compiler: Passt.

Carl D. schrieb:

> Ich dachte immer NOP braucht nur Zeit, aber rechnet zu mindest nichts
> falsch.

Ist auch der Fall. INT_MIN/32 = -2147483648, und damit ist es doch 
dieselbe Konstellation wie -32768 für int/16.


Karl schrieb:
> Dafür schleppe ich dann für den unwahrscheinlichen Fall, dass jemand
> wirklich mal mit einem Wert von -32,768m rechnet und den in ein unsigned
> Int packt immer die Prüfabfrage mit rum.

Die Prüfabfrage ist doch verschwindend gering. Aber wenn man eine 
Library macht, die nicht für eine konkrete Anwendung ist, in der man die 
Wertebereiche kennt, dann sollte man das halt auch richtig machen.

Daß ausgerechnet das zum Flaschenhals in der Performance wird, halte ich 
für ausgeschlossen. Und wenn doch, dann ist die Applikation 
wahrscheinlich falsch entworfen und enthält tonnenweise Jojo-Code.

Bevor hier weiter über evtl. vorhandene Fehler in der Library und 
fiktive 32bit Integer geschrieben wird, sollte jemand nachschauen was 
die xc8 Dokumentation zu der itoa Funktion sagt. Ich konnte in den 
letzten 5 Minuten keine Informationen finden, war aber auch nicht bereit 
den xc8 zu installieren. Ich vermute, itoa wird nirgendwo beschrieben 
und ist damit nicht zur Benutzung vorgesehen. Damit wäre jede Diskussion 
über den geposteten Quelltext überflüssig.

Carl D. schrieb:

> Auf einer 32-Bit-Maschine ist INT_Min/32 != INT_Min.

Das war auch nicht als Arithmetik gedacht, sondern als "INT_MIN für den 
Fall eines vorzeichenbehafteten 32bit-Integers". Ich war so frei, dieses 
Ausmaß an eigenständigem Mitdenken einfach mal vorauszusetzen.

Nop schrieb:
> Die Prüfabfrage ist doch verschwindend gering. Aber wenn man eine
> Library macht, die nicht für eine konkrete Anwendung ist, in der man die
> Wertebereiche kennt, dann sollte man das halt auch richtig machen.

Und was ist in dem Fall richtig?

Ich hatte letztens den Fall: Division durch Null.

Normalerweise liefert die Assembler-Division dann einfach den 
Eingangswert wieder zurück. Was mathematisch nicht korrekt ist, aber 
abgefangen werden kann.

Nun hat der Compiler sich entschieden, da eine 32-bit-Division aus einer 
Lib einzubauen. Die liefert dann bei Division durch Null eine Exception. 
Was auch korrekt ist.

Dummerweise lief das auf einem µC, der natürlich keine Exception 
ausgibt. Also wurde der µC in eine Endlosschleife geschickt. Das ist 
jetzt nicht das, was man auf einem µc möchte.

Karl schrieb:
> Ja stimmt, aber andererseits: Für 99.999% der Fälle irrelevant. Denn
> wenn ich reale Werte speichere, wird ein Integer seltenst komplett
> ausgereizt.

Das ist sehr gefährlich und verhindert auch nur einigermaßen 
professionellen Code.

Ich habe nichts dagegen, wenn jemand ein int i mit i++ überlaufen lässt, 
solange er
- das für seinen Compiler und Environment prüft, dass dies ohne WW3 
starten nach INT_MIN überläuft
- sich dessen bewusst ist
- das angibt, falls andere es nutzen
- exemplarisch entsprechende Asserts zur Compilezeit oder hier zur 
Laufzeit einbaut.

Das Problem fängt ja bei free-running-counter als Timer an, die weder in 
signed noch in unsigned sinnvoll, einfach und sicher nutzbar sind, es 
sei denn, man verlässt sich auf das vorliegende 2-er-Komplement.

Das Argument aber, dass es in 99.999% der Fälle gut geht, hat meist ein 
paar 9en zuviel. Sowohl das frei laufende i von oben, als auch der 
16-bit-ADC oder der 32-Bit Speicherwert laufen viel schneller in ein 
800xx als Du denkst.

Karl schrieb:

> Und was ist in dem Fall richtig?

Das Einfachste ist, man fragt hartcodiert auf INT_MIN ab und gibt für 
den Fall der Gleichheit ebenfalls hartcodiert den entsprechenden String 
zurück. Simpel, häßlich und zuverlässig.

Man sollte dann noch ein Compile-Time-Assert davorsetzen, daß INT_MIN 
auch tatsächlich das ist, was man glaubt, das es ist. Ein einfaches 
#ifdef mit #error tut's.

Wenn das von der Codegröße her bedenklich ist, dann ist es erst recht 
bedenklich, eine Libraryfunktion zu nutzen, die die Konvertierung zu 
diversen verschiedenen Basen beherrscht - denn das wird in diesem Umfang 
so gut wie nie gebraucht.

> Normalerweise liefert die Assembler-Division dann einfach den
> Eingangswert wieder zurück.

Je nach Controller, manche mögen es so und andere so. Manchmal kommt 
auch ein Interrupt oder Hardfault oder sowas. Deswegen validiere ich vor 
einer Division erstmal die Werte, und wenn eine Division durch 0 
anstünde, wird die Messung oder was auch immer dahintersteht als 
ungültig verworfen. Sowas kann insbesondere bei Zeitstempeln schnell mal 
passieren.

Nop schrieb:
> Das Einfachste ist, man fragt hartcodiert auf INT_MIN ab und gibt für
> den Fall der Gleichheit ebenfalls hartcodiert den entsprechenden String
> zurück. Simpel, häßlich und zuverlässig.

Ja aber was will ich denn auf einem µC mit einem String. Bei itoa mag 
das noch angehen, aber bei einem div / Null nützt mir das gar nichts.

Karl schrieb:

> Ja aber was will ich denn auf einem µC mit einem String.

Meßwerte oder so in einen String umzuwandeln, um das auf einem 
angeschlossenen Display anzuzeigen, ist ja durchaus üblich.

> aber bei einem div / Null nützt mir das gar nichts.

Doch, denn bei einer Division durch Variablen kann man sich Gedanken 
machen, wie es zustandekommen kann, daß im Nenner eine 0 steht. Das kann 
man abfangen und im einfachsten Fall die Messung für ungültig erklären.

Beispielsweise wenn man irgendeine zeitbezogene Größe berechnet und der 
Timertick sich nicht verändert hat, denn sowas kommt gerne vor, wenn ein 
Vorgang schneller als erwartet ist. Insbesondere, wenn der Vorgang 
selber auch noch parametriert ist und man daher nicht garantieren kann, 
daß er immer ausreichend lange dauert.

Schlußfolgerung: Meßdauer zu kurz. Entweder Messung verwerfen oder mit 
längerer Dauer nochmal versuchen.

Oder bei irgendwelchen Winkeln, wenn man z.B. einen Tangens braucht. 
Wenn der Winkel zu nahe an 90° ist, teilt man ebenfalls durch 0. 
Schlußfolgerung: Betrieb außerhalb des beabsichtigten Bereiches, und 
auch darauf kann man reagieren.

Nop schrieb:
> Doch, denn bei einer Division durch Variablen kann man sich Gedanken
> machen, wie es zustandekommen kann, daß im Nenner eine 0 steht.

Eine Division bekommt zwei Integer-Werte und gibt einen Integer zurück. 
Wie und wohin willst Du da einen String mit einem Fehler schreiben?

Sinnvoll wäre vielleicht, ein NaN zurückzugeben. Bei einem Projekt habe 
ich mal -32768 als Ganzzahl-NaN definiert, um damit ungültige Messwerte 
zu kennzeichnen. Das funktioniert aber schon nichtmehr, wenn man dann 
uint16 hat. Ist also auch nicht allgemein anwendbar.

Karl schrieb:

> Eine Division bekommt zwei Integer-Werte und gibt einen Integer zurück.
> Wie und wohin willst Du da einen String mit einem Fehler schreiben?

Gar nicht, ebensowenig wie bei itoa mit -32768 ein String mit einem 
Fehler geschrieben würde, sondern "-32768" als korrekter Ergebnis-String 
zurückgegeben.

Bei einer Division habe ich doch beschrieben, wie man das lösen kann. 
Grundsätzlich, indem man Eingabedaten bzw. Meßwerte vor der Verwendung 
in Berechnungen erstmal validiert. Denn das kann ja nur entweder an 
ungültigen Eingabedaten liegen, die man abfängt - oder alternativ 
natürlich an einem Fehler im Algorithmus, den man behebt.

Nop schrieb:
> Das Einfachste ist, man fragt hartcodiert auf INT_MIN ab und gibt für
> den Fall der Gleichheit ebenfalls hartcodiert den entsprechenden String
> zurück. Simpel, häßlich und zuverlässig.

Wieso hartcodiert? Zu welcher Basis? Du meinst sicher: Man ruft 
hartcodiert utoa mit -INT_MIN auf, oder?

(wobei ich nicht wüsste, wie man das korrekt, portabel und defined 
macht)

Achim S. schrieb:

> Wieso hartcodiert? Zu welcher Basis?

Ich habe signed ints noch nie zu irgendwas anderen als Basis 10 in 
Strings konvertiert, und besonders nicht embedded. Aber Dein Vorschlag 
...

> Man ruft hartcodiert utoa mit -INT_MIN auf, oder?

... ist natürlich noch besser.

> (wobei ich nicht wüsste, wie man das korrekt, portabel und defined
> macht)

Wieso nicht? -INT_MIN wird ja zur Compilezeit ausgewertet und steht als 
Konstante da.

Rolf M. schrieb:

> -INT_MIN ist das gleiche wie INT_MIN!

In einen signed int schon, zumindest bei Repräsentation im 
Zweierkomplement, aber doch nicht, wenn man das als Konstante zur 
Compilezeit an einen unsigned zuweist?!

OK, gerade mal testhalber ausprobiert: also es geht, allerdings kommt 
beim Compilieren die GCC-Warnung "Ganzzahlüberlauf in Ausdruck":

1

unsigned a = -INT_MIN;

Selbes, wenn man das so macht:

1

unsigned a = INT_MAX + 1;

So herum geht das ohne Warnung, allerdings verläßt sich das aufs 
Zweierkomplement:

1

unsigned a = INT_MIN;

Das hier geht auch ohne Zweierkomplement:

1

unsigned a = INT_MAX + 1U;

Naja, wenn man -INT_MIN zur Compile-Zeit macht, ändert das sicher kaum 
was am UB. Und alles andere ist m.E. übler, als sich (begründet, gprüft) 
darauf zu verlassen, dass einer- oder zweier-Komplement verwendet und 
angewandt wird.

Achim S. schrieb:
> Naja, wenn man -INT_MIN zur Compile-Zeit macht, ändert das sicher
> kaum was am UB.

Jepp, ich hatte nicht auf dem Schirm, daß auch der Compiler bei den 
statischen Ausdrücken keine Promotion macht.

> Und alles andere ist m.E. übler, als sich (begründet, gprüft)
> darauf zu verlassen, dass einer- oder zweier-Komplement verwendet und
> angewandt wird.

Prüfen kann man das ja leicht zur Compilezeit mit #ifs. Wenn 
Zweierkomplement, dann muß gelten -(INT_MIN + 1) == INT_MAX. Dann kann 
man beim hartcodierten Aufruf für den Fall INT_MIN einfach INT_MAX + 1U 
verwenden, ansonsten mit #error den denkbar unwahrscheinlichen Fall von 
Nicht-Zweierkomplement abfangen.

Rolf M. schrieb:

> Oder auch einfach nichts tun. Denn schließlich ergibt sich das Problem
> wie gesagt nur bei Zweierkomplement.

Dann ist es aber wieder zur Laufzeit undefined behaviour, was man auch 
nicht gerne in einer Lib haben will.

Rolf M. schrieb:
> Hä? Verstehe ich nicht. Das undefined behavior gibt es wie schon
> gesagt nur beim Zweierkomplement. Also muss ich nur dann was dagegen tun.

Ah, ich hatte Dein "einfach nichts tun" mißverstanden als "gar nichts 
tun", während es sich tatsächlich nur auf den "ansonsten"-Fall eines 
Postings bezog.

Nop schrieb:
> eines Postings bezog.

_m_eines Postings.