Strings und Newlib

[Oliver B. (irq)]

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!

[Karl H. (kbuchegg)]

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.

[Thomas W. (thomas100)]

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.

[Rolf Magnus (Gast)]

Warum eigentlich uint8_t statt dem eigentlich dafür vorgesehenen char?

[Klaus W. (mfgkw)]

und warum nicht #include <string.h>?

[Klaus W. (mfgkw)]

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.

[Oliver B. (irq)]

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.

[Link zu (Gast)]

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.".

[Oliver B. (irq)]

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...