Größe von String herausfinden

Für welche Programmiersprache willst du das denn wissen?

Ich gehe mal aus daß es sich um C handelt. Soweit ich mich beim K&R 
erinnere ist das eine der ersten Funktionen die überhaupt behandelt 
werden.

Wenn du das also nicht weisst, dann hast du noch nicht mal die ersten 
beiden Kapitel deines C Buchs durchgearbeitet.
Wenn du mit so wenig Grundlagen versuchst zu programmieren kann das nur 
mit Schiffbruch enden.

Also nimm oder besorge dir ein C Buch. Arbeite das durch, dann wird das 
was.

Dein Array sieht im Speicher so aus:

'H','a','l','l','o',0
Die Null entweder selbst suchen (sehr praktisch wenn man den String 
sowiso Buchstabe für Buchstabe abarbeiten muss) oder siehe Peter II

Einem C-Anfänger sei ohnehin angeraten sich mit den Fussangeln zu 
beschäftigen die nullterminierte Strings mit sich bringen, auf dass sein 
Produkt nicht irgendwann zum Gegenstand einer Sicherheitswarnmeldung 
wird.

Schau ob deine Implementation strnlen() anbietet, aber sei gleichzeitig 
behutsam mit willkürlichen Längenbeschränkungen, die sollten 
dokumentiert werden wenn mit Strings gearbeitet wird die im Zusammenhang 
mit Dateien oder Netzwerkverkehr stehen.
Eine einfache strlen()-Implementation kann man mit unbrauchbaren Daten 
zB vom Netz oder aus einer manipulierten/fehlerhaften Datei schnell dazu 
bewegen sehr hohen Ressourcenverbrauch und/oder einen Programmabsturz 
herbeizuführen.

Jepp, und genau der Fehler zweiter Ordnung ist dann schnell gemacht - 
strlen() zur Überprüfung einzusetzen ...

Boahh schrieb:
> Sinnvollerweise verwendet man das Nullte Byte des Strings um die Laenge
> festzuhalten.

Bist du von BASIC Strings mit maximal 255 Zeichen gewohnt?

Passend dazu ein netter Artikel:
http://www.joelonsoftware.com/articles/fog0000000319.html

Nur wie man in C bei konstanten Strings nun besser als mit strlen 
vorgeht hat bisher noch keiner gesagt, würde mich aber interessieren, da 
ich selbst keine Lösung wüsste, außer Pascal-Strings und von Hand 
zählen. Aber gegen Verzählen ist man dann auch nicht abgesichert?

Hallo Chris,

Chris schrieb:
> ich habe mir eine Funktion geschrieben, die einen String übergeben
> bekommt. In der weiteren Berechnung benötige ich nun aber auch die Länge
> des Strings. Ist es möglich diese mit einem Befehl zu ermitteln oder
> muss ich sie auch übergeben?
>
>

1

> void function(char array[]) {

2

> ...

3

>

Damit Du zur Abwechslung auch mal eine Antwort bekommst, mit der Du als 
Anfänger etwas anfangen kannst:
Die Programmiersprache C (oder C++, die in dem Fall eine echte Obermenge 
ist) übergibt an dieser Stelle faktisch nur einen Zeiger auf ein Array, 
das Elemente vom Typ Char enthält. Du kannst also die Länge des Strings 
nur dann erkennen, wenn sie aus dem String selber erkennbar ist, z. B. 
wenn der String nullterminiert ist.

Wenn Du z. B. einen Aufruf machst

1

function("ABC");

, dann übergibt der Compiler faktisch

1

function(['A', 'B', 'C', '\0']);

.

In diesem Fall kannst Du strlen() benutzen und es liefert 3 (das 
versteckte Nullbyte wird nicht mitgezählt). Wenn Du aber an der Stelle 
nur z. B. ein Array ['A', 'B', 'C'] übergibst, dann hast Du keine Chance 
herauszufinden, wie lang das Array tatsächlich ist und brauchst einen 
zusätzlichen Parameter für die Länge.

Falls Du C++ benutzt, so gibt es Arrayklassen, z. B. in der STL, wo die 
Länge implizit übergeben wird.

Tschüß, Matthias

короткое троль schrieb:
> Auf einem Controller...

Unwahrscheinlich, daß es hier um Controller geht:

Chris schrieb:
> return EXIT_SUCCESS;

Matthias H. schrieb:
> Damit Du zur Abwechslung auch mal eine Antwort bekommst, mit der Du als
> Anfänger etwas anfangen kannst:

Das ist unfair, denn den wirklich sinnvollen Vorschlag bekam er ziemlich 
zu Anfang:

Udo Schmitt schrieb:
> Also nimm oder besorge dir ein C Buch. Arbeite das durch, dann wird das
> was.

Zumal C++ hier auch nicht hilfreich ist, und das ebenfalls nur verwirrt:
Matthias H. schrieb:
> , dann übergibt der Compiler faktischfunction(['A', 'B', 'C', '\0']);

Wie du selber weisst, wird eben bei einem String in C gerade nicht ein 
Feld übergeben, sondern nur die Anfangsadresse.



Anstatt hier anhand von Gerüchten C zu lernen, wäre der gute Mann 
wirklich mit einem guten Buch besser bedient - was er sich selber hätte 
denken können.

Boahh schrieb:
> Ein Nullterminierter C-Stringist etwas vom Duemmlichsten, das man sich
> vorstellen kann.

Ich finde es genial.
Es macht die Verarbeitung sehr einfach und effizient.
Teilstrings lassen sich direkt parsen ohne ständige Kopier-Orgien.
Z.B. wenn ich ein Intel-Hex File einlese und binär in den Flash 
schreibe.

Boahh schrieb:
> Die Laenge braucht man ja eh sowieso.

Wozu denn?
Dann müßte ja mein Code haufenweise strlen() beinhalten, tut er aber 
nicht. Das ist eine der am wenigsten verwendeten Funktionen.
Z.B. ein Parser bricht einfach ab, sobald er das 0-Byte erkennt. Wann 
das ist, ist ihm sowas von egal.

Auch eine extra Längenangabe schützt überhaupt nicht vor Pufferüberlauf. 
Das muß jeder Programmierer selber absichern:

1

  if( idx >= sizeof(buffer))

2

    return ERROR;

3

  else

4

    buffer[idx] = irgendwas;

Oder man hat ein OS, was dynamisch Speicher vergrößert, sobald die 
aktuelle Länge überschritten wird. Das kostet natürlich massig Overhead.

Peter Dannegger schrieb:
> Boahh schrieb:
>> Ein Nullterminierter C-Stringist etwas vom Duemmlichsten, das man sich
>> vorstellen kann.
>
> Ich finde es genial.
> Es macht die Verarbeitung sehr einfach und effizient.

Wenn man es von der einfachen Implementierbarkeit der Standardbibliothek 
absieht, ist eher das genaue Gegenteil der Fall. Siehe dazu z. B. den 
Artikel auf joelonsoftware, zu dem oben jemand einen Link gepostet hat 
und der den Unterschied zu "Pascal-Strings" erklärt (die zu Zeiten von 
Turbo Pascal gängig waren, in neueren Sprachen der Pascal-Familie wie 
Ada oder Delphi funktioniert das etwas anders und die Längengrenze von 
255 Zeichen ist entfallen).

> Teilstrings lassen sich direkt parsen ohne ständige Kopier-Orgien.
> Z.B. wenn ich ein Intel-Hex File einlese und binär in den Flash
> schreibe.

Das ist aber "Zufall", weil das Format von Intel-Hexfiles eben extra so 
entworfen wurde, daß es keine Binärdaten enthält. Würde man die Daten 
noch mal zwischenpuffern und mit C-Stringfunktionen weiterverarbeiten, 
so würde das höchstwahrscheinlich schiefgehen. Daher sollte man es 
dringend lassen, in C-Strings allgemeine Daten abzulegen. In Sprachen, 
die die Stringlänge unabhängig vom Inhalt speichern, kann man es dagegen 
riskieren, ich habe das früher in Turbo Pascal und Delphi öfters 
gemacht.

> Auch eine extra Längenangabe schützt überhaupt nicht vor Pufferüberlauf.
> Das muß jeder Programmierer selber absichern:
>

1

>   if( idx >= sizeof(buffer))

2

>     return ERROR;

3

>   else

4

>     buffer[idx] = irgendwas;

5

>

Das ist ein völlig anderes Problem, da geht es nicht um die fehlende 
Längenangabe in Strings, sondern die fehlende Längenprüfung von Arrays. 
Auch da bieten modernere Programmiersprachen Abhilfe.

In einem frühen Pascal-Compiler sind irgendwann Längenprüfungen für 
Arrays eingeführt worden und man hat dann daraufhin die User gefragt, ob 
man das Feature nicht aus Performancegründen abschaltbar machen sollte. 
Die meisten haben sich dagegen ausgesprochen, weil man damit offenbar so 
viele Fehler gefunden hat! Tatsächlich gehen die meisten 
Sicherheitslöcher in C-Programmen einschl. Heartbleed auf solche oder 
ähnliche Fehler zurück, die in moderneren Sprachen einfach kaum 
passieren können (es sei denn, man schaltet die Prüfungen ab, soweit das 
möglich ist).

> Oder man hat ein OS, was dynamisch Speicher vergrößert, sobald die
> aktuelle Länge überschritten wird. Das kostet natürlich massig Overhead.

In dem Moment, wo die Laufzeitbibliothek/Standardbibliothek einer 
Programmiersprache Funktionen für dynamische Strings enthält, kann man 
auch die Speicherverwaltung auf die schnelle Allokation und Deallokation 
kleiner Speichermengen optimieren. Gerade in Umgebungen, wo es nicht auf 
jedes Byte ankommt, gibt es weitere Optimierungsmöglichkeiten, z. B. daß 
man die Buffergröße und Stringlänge getrennt verwaltet, sodaß nicht jede 
kleine Änderung an einem String Allokations-, Kopier- und 
Deallokationsoperationen nach sich zieht.

"Oder man hat ein OS, was dynamisch Speicher vergrößert, sobald die 
aktuelle Länge überschritten wird."

Die Speicherallokation wird vergrössert nicht der Speicher :)

Die einfachste strcpy-Implementation ist

while (*dest++=*source++);

Was soll da schon schiefgehen....

Peter II schrieb:
> Andy D. schrieb:
>> while (*dest++=*source++);
>>
>> Was soll da schon schiefgehen....

>nichts
Richtig. Wenn der Programmierer aufpasst.

Außerdem gibts ja auch noch die _s Funktionen, welche genau sowas 
verhindern sollen. Das da oben ist halt einfach mal ne echt schnelle und 
schlanke Methode. C halt. Nur hat C keine Sicherheitsgurte.

> (dest ist bestimmt ein objekt mit überladenen Operatoren)
Komischer Humor...

cyblord ---- schrieb:
> Außerdem gibts ja auch noch die _s Funktionen

Die sind ja die größte Lachnummer. In speziellen Fällen gelegentlich 
"sicherer"...

Klaus Wachtler schrieb:
> cyblord ---- schrieb:
>> Außerdem gibts ja auch noch die _s Funktionen
>
> Die sind ja die größte Lachnummer. In speziellen Fällen gelegentlich
> "sicherer"...

Narrensicherheit wirst du halt bei C nicht finden. Das macht die Sprache 
nicht schlechter. Du kannst C nicht mit Pascal oder Java vergleichen. 
Wer die Freiheit von C nicht erträgt, kann sie duch die Sicherheit von 
höheren Sprachen aufgeben.

gruß cyblord

Chris schrieb:
> Meine Funktion bekommt einen String übergeben, der auf einem LCD
> angezeigt wird. Dann gebe ich jedes Zeichen aus, bis der Inhalt 0 ist.
> Den Inhalt gebe ich im Quellcode vor, den Speicher werde ich also nicht
> überlasten. Ich könnte natürlich auch immer die Länge übergeben, aber so
> gefällt es mir besser.
Na wo ist dann das Problem ?

Du gibst selbst die Strings vor und niemand anders ändert die.
Ob Du das mit einer terminierenden 0 oder Längenangabe hoch 3
machst ist doch völlig egal.

Im schlimstem Fall erscheint Müll auf dem Display ;)

cyblord ---- schrieb:
> Narrensicherheit wirst du halt bei C nicht finden.

Das erwarte ich gar nicht.
Ich arbeite viel mit C, und mag es (C++ natürlich lieber).

Ich mokiere mich nur über die Pseudosicherheit der ..._s-Funktionen.
Die verdecken mehr, als sie helfen.

cyblord ---- schrieb:
> Außerdem gibts ja auch noch die _s Funktionen, welche genau sowas
> verhindern sollen.

Unter einigen Betriebssystemen (ursprünglich OpenBSD, auch andere BSDs, 
Mac OS X, Solaris, ...) gibt es strlcpy() und strlcat(). Die Funktionen 
haben eine meiner Meinung nach außerordentlich gelungene Semantik, um 
strcpy() und strcat() weitestgehend zu ersetzen. Auf Plattformen, wo es 
sie nicht in der Standardbibliothek gibt, schreibe ich sie mir gerne 
selber.
Siehe dazu auch http://www.courtesan.com/todd/papers/strlcpy.html .

Es gab schon Programmfehler in der Geschichte bei denen es jahrelang 
funktionierte weil hinter dem String irgendetwas allokiert und immer zu 
dem Zeitpunkt auf 0 gesetzt war als dieser gelesen wurde...

Andy D. schrieb:
> Es gab schon Programmfehler in der Geschichte bei denen es jahrelang
> funktionierte weil hinter dem String irgendetwas allokiert und immer zu
> dem Zeitpunkt auf 0 gesetzt war als dieser gelesen wurde...

Wenn es funktioniert ist es auch kein Fehler ;)

@scheppertreiber wenn das eine bewusste und dokumentierte Optimierung 
ist ist es vielleicht kein Fehler, sonst schon ...

Aber diese Zahl hilft dir nichts ohne die zugehörige Maßeinheit.
Ist XL jetzt 52? Oder 48? War es doch 92?

Also bleibt nichts übrig als anprobieren, d.h. strlen().