Forum: Mikrocontroller und Digitale Elektronik Stringende in C bei µC


von Alex G. (almalex)


Lesenswert?

hi
gibt es ausser dem \0 noch irgendwelche Ascii zeichen die dazu führen 
dass in C das ende eines strings makiert wird? weil bei mir sendet der 
µC nie alle zeichen die in dem String stehen, und ich schreibe random 
ascii zeichen rein
danke und mfg alex

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> und ich schreibe random ascii zeichen rein
Wo rein?
Quellcode bitte.

von Walter T. (nicolas)


Lesenswert?

Nicht daß ich wüßte, aber es gibt noch einige Zeichen, die die Ausgabe 
in einem Terminal-Programm beeinflussen.

Siehe: http://de.wikipedia.org/wiki/VT100

von Tobi (Gast)


Lesenswert?

> gibt es ausser dem \0 noch irgendwelche Ascii zeichen die dazu führen
> dass in C das ende eines strings makiert wird?

Nein.

von Peter (Gast)


Lesenswert?

Alex Glaser schrieb:
> und ich schreibe random ascii zeichen rein

dann ist es aber kein String mehr. Dafür gibt es ja in C den void*, dazu 
dann noch die Länge und schon kannst du auch \0 senden.

von Klaus W. (mfgkw)


Lesenswert?

Das hat mit void* jetzt aber ziemlich genau nichts zu tun.
Ein char* kann auf einen nullterminierten String zeigen,
oder auf einen nicht mit 0 terminierten (und ebenso auf ein
einzelnes char natürlich).
Ebenso wie void*.

Welche der möglichen Bedeutungen ein char* hat, muß der
Programmierer wissen.

von Peter (Gast)


Lesenswert?

Klaus Wachtler schrieb:
> Das hat mit void* jetzt aber ziemlich genau nichts zu tun.

Es macht aber deutlich das es keine string ist und das man auch nicht 
mit den String funktionen arbeiten sollte.

von Klaus W. (mfgkw)


Lesenswert?

Und es macht vor allem besonders deutlich, daß der void* auf char
zeigt, oder was?

Und wie kommst du auf die Schnapsidee, daß void* dafür eingeführt wurde?

Sorry, aber diese Behauptung ist etwas verwegen und nicht
gerade zielführend.

Wenn man einen Zeiger auf char hat, wird doch kein vernünftiger
Mensch den als void* deklarieren.

Es gibt keine unterschiedlichen Datentypen für terminierte
und nichtterminierte Strings in C.

von Peter (Gast)


Lesenswert?

Klaus Wachtler schrieb:
> Und wie kommst du auf die Schnapsidee, daß void* dafür eingeführt wurde?
wo habe ich das geschrieben? Ich habe gemeinst das für beliebiege Daten 
ein void* geeigneter ist als ein char*

> Wenn man einen Zeiger auf char hat, wird doch kein vernünftiger
> Mensch den als void* deklarieren.
und warum nicht? Wenn ich in einem C Programm ein char* sehen, dann gehe 
ich erstmal davon aus das ich ihn z.b. mit Printf ausgeben kann. Bei 
void*  weiss ich schon mal das das nicht geht bzw. sinnvoll ist.

> Es gibt keine unterschiedlichen Datentypen für terminierte
> und nichtterminierte Strings in C.
das ist ja klar, weil es ja in C überhaupt keine strings gibt - es gibt 
nur zeiger.

von Oktoberfestbesucher (Gast)


Lesenswert?

chr$(27) = esc zeigt eventuel das Ende von einem String an.

Du musst es einfach mal systematisch durchtesten, um zu identifizieren, 
welches zeichen deien String beendet.

von Andreas F. (aferber)


Lesenswert?

Peter schrieb:
>> Wenn man einen Zeiger auf char hat, wird doch kein vernünftiger
>> Mensch den als void* deklarieren.
> und warum nicht? Wenn ich in einem C Programm ein char* sehen, dann gehe
> ich erstmal davon aus das ich ihn z.b. mit Printf ausgeben kann. Bei
> void*  weiss ich schon mal das das nicht geht bzw. sinnvoll ist.

Wenn man die "Unterminiertheit" eines Strings im Code sichtbar machen 
will, dann macht man das mit einem geeigneten typedef, nicht mit einem 
void*. Letzterer hat in vielen Punkten eine andere Semantik als jeder 
andere Pointer-Typ. Schonmal versucht, Zeigerarithmetik mit void* zu 
machen? (Ja, ich weiss, mit GCC geht es, das ist aber eine 
GCC-Erweiterung)

Jeder mit ein bisschen Erfahrung in C weiss bei einem "char *", dass man 
den nur dann den Standard-Stringfunktionen vorwerfen darf, wenn das 
Zeigerziel ein paar Zusatzbedingungen erfüllt (\0-terminiert für 
Input-Parameter, ausreichend Platz vorhanden bei Output-Parametern 
etc.). Nichtmal bei allen Funktionen aus string.h ist immer garantiert, 
dass der String terminiert ist, siehe z.B. strncpy().

Andreas

von Peter (Gast)


Lesenswert?

Andreas Ferber schrieb:
> Wenn man die "Unterminiertheit" eines Strings im Code sichtbar machen
> will, dann macht man das mit einem geeigneten typedef, nicht mit einem
> void*.

und was hat eine block von zufallsdaten überhaupt noch mit einem String 
zu tun? Es geht ja gerade darum das darin "irgend etwas" ist. Damit ist 
das für mich kein String sondern es sind Daten.

von Stefan E. (sternst)


Lesenswert?

Peter schrieb:
> und was hat eine block von zufallsdaten überhaupt noch mit einem String
> zu tun? Es geht ja gerade darum das darin "irgend etwas" ist. Damit ist
> das für mich kein String sondern es sind Daten.

"zufallsdaten" hast erst du daraus gemacht. Dem OP nach sollen es 
zufällige ASCII-Zeichen sein.

Peter schrieb:
> Alex Glaser schrieb:
>> und ich schreibe random ascii zeichen rein
> dann ist es aber kein String mehr.

Warum soll das kein String sein? Definierst du einen "String" etwa 
darüber, ob die Abfolge der Zeichen darin irgendeinen Sinn ergibt?

von Peter (Gast)


Lesenswert?

> und ich schreibe random ascii
ok ich habe das ascii überlesen, dann ist es ein string und man sollte 
es auch ein char* sein.

von Andreas F. (aferber)


Lesenswert?

Peter schrieb:
> und was hat eine block von zufallsdaten überhaupt noch mit einem String
> zu tun? Es geht ja gerade darum das darin "irgend etwas" ist. Damit ist
> das für mich kein String sondern es sind Daten.

Selbst dann wäre void* schlicht semantisch falsch, stattdessen wäre z.B. 
uint8_t* angebracht.

void* zeigt auf "irgendetwas", aber nicht auf etwas mit "irgendetwas" 
drin. Es gibt kein Array von void!

Andreas

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.