www.mikrocontroller.net

Forum: Compiler & IDEs Strings und Newlib


Autor: Oliver B. (irq)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Situation: ARM Toolchain mit Newlib als C-Bibliothek. Selbst 
geschriebenes Makefile.

Problem: String-Deklarationen funktionieren nicht.

Beispiel:
#include "string.h"   // Eclipse Warnung: "Unresolved inclusion"
uint8_t* file_name = "test";

Wenn ich nun im Debugger den Speicher auslese steht da "\032`A\362" 
drin, sizeof(file_name) liefert den Wert 4, obwohl es eigentlich 5 sein 
müsste, wegen der terminierenden '\0'.

Ich vermute, dass der Übeltäter mein Makefile ist, zumal Eclipse bei 
string.h eine "Unresolved inclusion" meldet. Es handelt sich um ein von 
Hand geschriebenes Makefile, kein von Eclipse erzeugtes. Hat jemand 
einen Tipp, wie ich das hinbiegen könnte? Brauche ich Newlib/string.h 
dazu, wenn ja, wie binde ich das richtig ein?

Vielen Dank!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver Behr schrieb:

> Beispiel:
>
>
> #include "string.h"   // Eclipse Warnung: "Unresolved inclusion"
> uint8_t* file_name = "test";
> 
>
> Wenn ich nun im Debugger den Speicher auslese steht da "\032`A\362"
> drin, sizeof(file_name) liefert den Wert 4, obwohl es eigentlich 5 sein
> müsste, wegen der terminierenden '\0'.

Bist du sicher, dass du nicht den Speicher ansiehst, der den Pointer zum 
String beherbergt anstatt dem String selber?

und nein. sizeof(file_name) wird ziemlich sicher nicht 5 sein. 4 klingt 
plausibel, wenn wir davon ausgehen, dass ein Pointer auf deinem System 
eine Länge von 4 Bytes hat, was bei einem ARM nicht ungewöhnlich sein 
sollte.

Ich denke, du wolltest eigentlich schreiben

uint8_t file_name[] = "test";

>
> Ich vermute, dass der Übeltäter mein Makefile ist, zumal Eclipse bei
> string.h eine "Unresolved inclusion" meldet. Es handelt sich um ein von

Was Eclipse meldet, ist uninteressant.
Interessant ist, ob dein Compiler die string.h findet oder nicht.

Du verwechselst die IDE mit dem Compiler.

Autor: Thomas Weyhrauch (thomas100)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sizeof(file_name) liefert 4, weil file_name ein pointer ist. Und der hat 
wohl 4 byte.

Was du willst, kann C von haus aus nicht. strlen () ist dein Kandidat. 
Damit bekommst du die stringlänge raus.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum eigentlich uint8_t statt dem eigentlich dafür vorgesehenen char?

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und warum nicht #include <string.h>?

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Weyhrauch schrieb:
> Was du willst, kann C von haus aus nicht. strlen () ist dein Kandidat.
> Damit bekommst du die stringlänge raus.

nur zur Sicherheit: strlen() liefert die Länge ohne abschließende 0.

Autor: Oliver B. (irq)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ist alles klar, vielen Dank für die Antworten.

Zu sizeof(): Natürlich gibt das die Pointergröße, strlen() wäre das 
Richtige gewesen...

EDIT: Compileroptionen waren nicht das Problem.

Es funktioniert nur mit der Schreibweise:
char        teststring2[] = "t22";

Auch ohne geänderte Compileroptionen. Die Debug-Session zeigts...

Viele Grüße, Oliver.

Autor: Link zu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Warum eigentlich uint8_t statt dem eigentlich dafür vorgesehenen char?
Das Frage ich mich die ganze Zeit schon, die Erfahrungen der letzten 
Zeit lehrten mich aber, so etwas nicht mehr zu fragen. ;-)

Klaus Wachtler schrieb:
> und warum nicht #include <string.h>?
#include "string.h"
 und ähnliches ist eine Unsitte, die ich schon öfter gesehen habe, die 
Antwort lautet vermutlich: "Ich weiß dass soll man nicht machen, aber es 
funktioniert ja.".

Autor: Oliver B. (irq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Link zu schrieb:
> #include "string.h" und ähnliches ist eine Unsitte, die ich schon öfter gesehen 
habe, die
> Antwort lautet vermutlich:

Nicht ganz, ich hatte es zuerst natürlich als <string.h> aber als das 
"nicht funktionierte" habe ich in meiner Ratlosigkeit auch die andere 
Variante probiert.

Wie dem ach sei. Ich habe übrigens die Ursache gefunden, dafür, dass die 
Strings bei mir nicht wirklich funktioniert haben: Ich hatte in meinem 
selbstgeschriebenen Linkerscript die rodata Einträge noch nicht 
aufgenommen.

*(.rodata .rodata.* .gnu.linkonce.r.*)

brachte Abhilfe. Vielleicht ist gut kopiert doch besser als schlecht 
selbst gemacht...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.