wegen extern gibt es keine Fehlermeldung, aber auch kein brauchbares
itoa.
Was soll das? Warum ist itoa in codeRed nicht enthalten und wie
aktiviere ich es am sinnvollsten?
karl k. schrieb:> erst beim debuggen stellt man fest, dass itoa gar nicht vorhanden ist.
Nein, das sollte lange vorher beim Linken einen Fehler werfen.
karl k. schrieb:> Der Dubugger zeigt die Fehlermeldung:> No source available for "itoa() at 0xab1c"
Ja, und? Keine Sourcen davon da, aber es reicht ja, wenn die
Binaries in der Bibliothek liegen. Funktioniert also.
funktioniert leider nicht. Wie krieg ich die binaries aus der Bibliothek
raus?
Ich habe jetzt eine itoa-Funktion neu eingebunden. Fehlermeldung
conflicting types. Also das neue funktionierende itoa in x_itoa
umbenannt. Das geht jetzt. Aber ich hätte gerne das defekte itoa aus der
Bibliothek ganz raus.
karl k. schrieb:> funktioniert leider nicht.> Aber ich hätte gerne das defekte itoa aus der> Bibliothek ganz raus.
Woher weißt du dass es nicht funktioniert? Es ist schon sehr
unwahrscheinlich, dass kaputter Code in einer libc landet.
karl k. schrieb:> funktioniert leider nicht. Wie krieg ich die binaries aus der Bibliothek> raus?
Jetzt willst du sie auf einmal rauskriegen? Davor hast du behauptet, sie
seien nicht drin, und du hast gefragt, wie du sie reinkriegst.
> Also das neue funktionierende itoa in x_itoa umbenannt. Das geht jetzt.> Aber ich hätte gerne das defekte itoa aus der Bibliothek ganz raus.
So einfach eine einzelne Funktion aus der libc zu entfernen dürfte
schwierig werden. Aber ich hab da so meine Zweifel, daß die wirklich
kaputt ist. Wie rufst du sie denn auf, was erwartest du als Ergebnis und
was passiert stattdessen?
das war der alte Aufruf der nicht funktionierte:
itoa (var_array[b],var_conversion_buffer,10);
das ist der neue Aufruf der funktioniert:
//setzt den Wert der Variable var_array[b] als string in
//var_conversion_buffer ein.
x_itoa (var_array[b],var_conversion_buffer,10);
Es funktioniert jetzt genauso wie es soll. Mit dem alten itoa ging es
nicht.
Vielleicht ist itoa für 8bit anderst als für 32bit. Ich finde jedenfalls
die Datei nicht, in der das alte itoa steht.
karl k. schrieb:> Vielleicht ist itoa für 8bit anderst als für 32bit.
Logischerweise ja.
karl k. schrieb:> Ich finde jedenfalls> die Datei nicht, in der das alte itoa steht.
Datei-Suchfunktion und "nm" verwenden.
karl k. schrieb:> Vielleicht ist itoa für 8bit anderst als für 32bit. Ich finde jedenfalls> die Datei nicht, in der das alte itoa steht.
Welchen Datentyp hat denn var_array[b]?
Vielleicht willst du ja eigentlich auch nicht itoa verwenden sondern
ltoa, weil var_array[b] ein long ist?
Woran man alles denken muss. Das jetzt verwendete x_itoa macht aus einem
int ein char-array. Bei einem 8-bitb itoa ist das vielleicht anders.
Ich danke jedenfalls für die wie immer hilfreichen Denkanstöße von
allen.
Die Suche nach dem alten itoa habe ich aufgegeben. Wahrscheinlich ist es
ein 8bit itoa aus lange zurückliegenden Programmierversuchen.
leluno schrieb:> Woran man alles denken muss. Das jetzt verwendete x_itoa macht aus einem> int ein char-array. Bei einem 8-bitb itoa ist das vielleicht anders.
Es gibt kein 8_bit itoa.
Das i in itoa steht für 'int'.
> Die Suche nach dem alten itoa habe ich aufgegeben. Wahrscheinlich ist es> ein 8bit itoa aus lange zurückliegenden Programmierversuchen.
Whrscheinlich ... ist es, dass der eigentliche Fehler in deinem Code zu
suchen ist und nicht in itoa. itoa ist zu primtiv, so dass man davon
ausgehen kann, dass die Implementierung korrekt ist.
Nur: von deinem Code zeigst du ja immer nur homöpathische Dosen.
Irgendetwas gesichertes kann man darüber nicht aussagen. Zumal es ja
noch nicht einmal sicher gestellt ist, dass überhaupt die Konvertierung
das Problem ist. Das Problem könnte ja auch ganz woanders stecken und
was du siehst, sind nur die Symptome, die dich (fälschlicherweise) in
Richtung itoa lenken. Dass es mit deiner Version funktioniert, ist mir
als Argument zu wenig, denn mit einer eigenen Version hast du
grundsätzlich das Programm verändert und damit kann dann auch das
Symptom gesprungen sein, weil zb das Speicherlayout anders ist.
Bei jemandem der so etwas ...
> erst beim debuggen stellt man fest, dass itoa gar nicht vorhanden ist.
... von sich gibt, gehe ich von allem aus, nur nicht davon, dass das
mitgelieferte itoa fehlerhaft ist.
das mitgelieferte itoa ist mit Sicherheit nicht fehlerhaft. Da bei
codeRed aber kein itoa mitgeliefert wird - ich habe jedenfalls mit der
Windows-Suche keine Datei gefunden, die diese Funktion enthält - kann es
sich nur um ein AVR-itoa handeln, welches bei der Anpassung von
AVR-LCD-Text mit in den ARM-Code geraten ist.
Jedenfalls fällt der Fehler erst beim Debuggen auf, da das itoa - als
source nicht vorhanden - nicht angesprungen wird.
Die Interpretation der Meldung
> No source available for "itoa() at 0xab1c"
als itoa ist nicht vorhanden, ist vielleicht etwas laienhaft.Die
Schlussfolgerung, dass mit itoa irgendetwas nicht stimmt und dass man es
suchen muss, scheint mir aber durchaus richtig zu sein.
Das Problem festzustellen, was an die Stelle 0xab1c geladen wurde, ist
mit meinen Mitteln jedenfalls nicht zu lösen.
Ist aber auch egal, da es mit der Umbenennung einwandfrei funktioniert.
bei codeRed heißt es:
itoa() is non-standard library function which is provided in many other
toolchains to convert an integer to a string. To ease porting, the
LPCXpresso IDE provides two variants of this function in the Redlib C
library....
char * itoa(int value, char *vstring, unsigned int base);
char * uitoa(unsigned int value, char *vstring, unsigned int base);
Vielleicht beruht der Fehler darauf, dass ARM-itoa eine signed Eingabe
benötigt, aber nur unsigned geliefert wird?
leluno schrieb:> Vielleicht beruht der Fehler darauf, dass ARM-itoa eine signed Eingabe> benötigt, aber nur unsigned geliefert wird?
Wir können jetzt noch ewig im Kreis rätseln. Fakt ist, daß die Annahmen
des TO über die Ursache unsinning sind, und das Problem ganz woanders
liegt, aber nicht in itoa.
Den Rest beantworten Glaskugel und Kafeesatz.
Oliver
leluno schrieb:> ich habe jedenfalls mit der> Windows-Suche keine Datei gefunden, die diese Funktion enthält
Das "Problem" ist, dass du anscheinend noch immer nicht begriffen hast,
das etwas nur weil du keinen Source Code dafür hast, nicht 'nicht
mitgeliefert' wird.
Dein itoa steckt in der Bibliothek, die automatisch immer mit
dazugelinkt wird. Dort ist eine vorübersetzte Version davon enthalten.
Wenn dem nicht so wäre, dann hätte der Linker bereits Schwierigkeiten,
ein komplettes Programm zu erstellen.
> Jedenfalls fällt der Fehler erst beim Debuggen auf, da das itoa - als> source nicht vorhanden - nicht angesprungen wird.>> Die Interpretation der Meldung>> No source available for "itoa() at 0xab1c"> als itoa ist nicht vorhanden, ist vielleicht etwas laienhaft.Die> Schlussfolgerung, dass mit itoa irgendetwas nicht stimmt und dass man es> suchen muss, scheint mir aber durchaus richtig zu sein.
Die Schlussfolgerung ist einfach nur Unsinn.
Die Meldung des Debuggers bedeutet einfach nur, dass für itoa kein
Quellcode (also in C-Source Code Form) vorhanden ist. Nicht mehr und
nicht weniger. Und das ist nichts, was dich groß beunruhigen müsste. Das
itoa wurde vom Compiler Hersteller compiliert und das Object Code File,
zusammen mit vielen anderen, in eine Library gesteckt. Diese
Vorgehensweise ist absoluter Usus. Oder kannst du in printf
hinein-debuggen? Oder in malloc?
> Ist aber auch egal
Wenn es dir egal ist. Mir wäre es nicht egal.
leluno schrieb:> Vielleicht beruht der Fehler darauf, dass ARM-itoa eine signed Eingabe> benötigt, aber nur unsigned geliefert wird?
Das zeigt eigentlich nur, wie wenig du noch vom C-Typsystem verstehst.
itoa bzw uitoa können nicht unterscheiden, ob du ihnen einen signed int
gibst oder nicht. In erster Linie kriegen die beiden einen int. Das ist
erst mal das wichtigste, denn damit wird etwas darüber ausgesagt, wie
groß die sizeof des Argumentes ist. Ob das Argument von der Funktion
dann als signed int oder als unsigned int interpretiert wird, ist
dahingehend dann erst die 2.te Frage. Ein Fehler bei der
Argumentübergabe wirkt sich dahingehend aus, dass anstelle von negativen
Zahlen, dann eben größere positive Zahlen generiert werden.
Was aber zb nicht egal wäre, wäre wenn man dem itoa einen long rein
gibt. Denn dann kommt es tatsächlich zu ordentlichen Fehlern, weil der
long auf einen int runter-gestrippt wird.
alle drei liefern das richtige Ergebnis. Der Fehler war offensichtlich
in der Zeile unter itoa. Ich habe die Debugger-Meldung falsch
interpretiert. Problem geklärt.
Thread beobachten
Seitenaufteilung abschalten