Re: Was ist eine gueltige Message-ID?
Moin,
* Jan Trippler
On Sam, 03 Aug 2002 at 20:09 (+0200), Thorsten Haude wrote:
* Jan Trippler
[02-08-03 16:53]: On Sam, 03 Aug 2002 at 00:18 (+0200), Thorsten Haude wrote:
Ein String wird in C _immer_ nullterminiert! Es gibt keine Ausnahmen, ein String ist bei 0 zu Ende. Zeige mir _ein_ Beispiel, in dem das nicht so ist. char versuch[6] = {'k', 'a', 'p', 'u', 't', 't'};
Ein nicht terminierter String, der in jedem Programm Stress machen wird. Das was Du da fabriziert hast, ist einfach nur ein char-Array. Ein String (der als Datentyp in C übrigens nicht existiert) ist ein Null-terminiertes char-Array.
Ja was denn nun? Ein nicht terinierter String, der nicht existiert?
Siehe unten. Du drehst mir das Wort im Mund rum.
Die Gelegenheit war günstig.
versuch[6] ist ein char-Array. Natürlich kannst Du solche char-Arrays - wenn Du es möchtest - ohne 0-Terminierung anlegen (wenn es z. B. für Flags genutzt wird, ist das auch nicht nötig), aber wenn Du _irgendeine_ Stringfunktion drauf loslassen willst, dann _muss_ am Ende eine 0 stehen.
Die ist aber schon bewußt, daß diese Dinge auch durch Fehler anderswo bzw. durch Angriffe passieren können, oder? Darum sollte C-Code idR. so robust wie möglich sein, nicht so schnell wie möglich.
Es geht doch nur darum, daß diese ganze C-Eigenheit mit dem Zeiger-auf-Chararacter offensichtlich und bekannterweise nicht wasserdicht ist. Darum sollte man bei ihrer Benutzung keine Haare spalten, sondern auf Nummer sicher gehen.
Die Haarespalterei machst Du hier. Du behauptest seit Tagen, strcmp liest über die 0 hinweg und das ist Stuss.
Ich behaupte nur, daß ich nicht sicher wissen kann, daß es anders ist.
Du behauptest seit Tagen, dass die Benutzung von strcmp eine Sicherheitslücke ist und das ist Stuss
Ich behaupte, daß das Leben zu kurz und strncmp() zu billig ist, um darüber nachdenken zu müssen.
Ich entwickele seit einer Reihe von Jahren Programme u. a. in C für diverse Unix-Derivate (Reliant Unix, HP-UX, AIX, Solaris und vereinzelt SCO waren schon dabei), in keinem einzigen Fall hat der strcmp anders als in der glibc funktionert (intern vielleicht, aber er hat _immer_ bei 0 aufgehört).
Das ist gut, dann kennst Du vielleicht auch einen Beweis, der nicht nur anekdotisch ist. Daß es strcmp()s gibt, die sich so vernünftig verhalten, wie erwartet, haben wir ja schon geklärt.
[...]
P.S.: Du stellst einen Sachverhalt in Frage, der die Grundlage für das gesamte Stringhandling in C bildet.
Bitte? Welcher wäre das wohl?
s. o.
"Strings existierern nicht"? Das würde allerdings das gesamte Stringhandling beeinflussen.
Wieder einmal: Wenn Du zitierst, dann bitte korrekt. So langsam werde ich sauer. O-Ton Jan: ... Ein String (der als Datentyp in C übrigens nicht existiert) ... Ich habe also mitnichten behauptet, dass Strings nicht existieren, sondern dass sie _als Datentyp_ nicht existieren.
Tut mir leid, ich hätte es nicht als wörtliches Zitat markieren sollen, aber wenn es keinen Typ String gibt, gibt es auch keine Strings: Gerade darum muß man ja durch so viele Reifen springen, wenn man in C Strings verarbeitet.
Das "s. o." bezog sich auf die Nullterminierung, was jedem halbwegs aufmerksamen Leser wohl auch sofort aufgefallen wäre.
Du solltest nicht davon ausgehen, daß ich Gedanken lesen kann. Thorsten -- Auch Hunger ist Krieg. - Willy Brandt
On Sam, 03 Aug 2002 at 21:33 (+0200), Thorsten Haude wrote:
* Jan Trippler
[02-08-03 20:37]: Siehe unten. Du drehst mir das Wort im Mund rum.
Die Gelegenheit war günstig.
aber nicht glücklich gewählt - manche Leute (u. a. ich) reagieren sauer, wenn aus fachlicher Diskussion Polemik wird.
versuch[6] ist ein char-Array. Natürlich kannst Du solche char-Arrays - wenn Du es möchtest - ohne 0-Terminierung anlegen (wenn es z. B. für Flags genutzt wird, ist das auch nicht nötig), aber wenn Du _irgendeine_ Stringfunktion drauf loslassen willst, dann _muss_ am Ende eine 0 stehen.
Die ist aber schon bewußt, daß diese Dinge auch durch Fehler anderswo bzw. durch Angriffe passieren können, oder? Darum sollte C-Code idR. so robust wie möglich sein, nicht so schnell wie möglich.
Aber auch nur so komplex wie nötig. Auch das ist eine Frage der Robustheit. Man kann auch die Prüfungen im Programm übertreiben. Der Grundsatz sollte lauten: Jedes Datum aus einer unsicheren Quelle wird sofort bei seinem Eingang im Programm geprüft. Dann muss man das nicht bei jeder Operation noch mal machen (vor allem dann nicht, wenn das Datum - in diesem Fall der String - gar nicht verändert wird). Dein Aussage robust vs. schnell ist so absolut nicht richtig. Wie überall gilt auch hier: Aufwand und Nutzen müssen sich entsprechen.
Es geht doch nur darum, daß diese ganze C-Eigenheit mit dem Zeiger-auf-Chararacter offensichtlich und bekannterweise nicht wasserdicht ist. Darum sollte man bei ihrer Benutzung keine Haare spalten, sondern auf Nummer sicher gehen.
Die Haarespalterei machst Du hier. Du behauptest seit Tagen, strcmp liest über die 0 hinweg und das ist Stuss.
Ich behaupte nur, daß ich nicht sicher wissen kann, daß es anders ist.
Auch das ist Stuss.
Du behauptest seit Tagen, dass die Benutzung von strcmp eine Sicherheitslücke ist und das ist Stuss
Ich behaupte, daß das Leben zu kurz und strncmp() zu billig ist, um darüber nachdenken zu müssen.
Das habe ich gerade in meiner Mail an Andre Heine geschrieben: Genau das *nicht darüber nachdenken* ist gefährlich. Und strncmp() ist allein vielleicht billig, wenn aber mehrere zigtausend Durchläufe diesen zusätzlichen Aufwand treiben, sicher nicht mehr. Das Aasen mit den zur Verfügung stehenden Ressourcen ist auch nicht gerade das Nonplusultra guter Programmierung.
Ich entwickele seit einer Reihe von Jahren Programme u. a. in C für diverse Unix-Derivate (Reliant Unix, HP-UX, AIX, Solaris und vereinzelt SCO waren schon dabei), in keinem einzigen Fall hat der strcmp anders als in der glibc funktionert (intern vielleicht, aber er hat _immer_ bei 0 aufgehört).
Das ist gut, dann kennst Du vielleicht auch einen Beweis, der nicht nur anekdotisch ist. Daß es strcmp()s gibt, die sich so vernünftig verhalten, wie erwartet, haben wir ja schon geklärt.
*anekdotisch* - Du verstehst es, Dinge in das rechte Licht zu rücken :-( - Du stehst nicht zufällig bei der nächsten Wahl als Kandidat auf einer Liste? Um eine weitere Anekdote hinzuzufügen: auch im Borland Turbo C++, Borlands C++-Builder und in M$ Visual C++ hören die strcmp bei der ersten Null auf. Kehren wir die Frage mal um: Kennst du einen strcmp(), der sich _nicht_ so vernünftig verhält? Oder wie wärs mal mit ein wenig Logik? strcmp ist (neben strncmp) eine _String_-Funktion. Strings sind nullterminierte char-Arrays. Welchen Sinn sollte es für eine String-Funktion machen, einen String über seinen Terminator hinaus zu bearbeiten? [...]
Tut mir leid, ich hätte es nicht als wörtliches Zitat markieren sollen, aber wenn es keinen Typ String gibt, gibt es auch keine Strings: Gerade darum muß man ja durch so viele Reifen springen, wenn man in C Strings verarbeitet.
Auch dies ist wieder mal eine typisch Haude'sche Schlussfolgerung. Natürlich gibt es in C Strings: Das sind nullterminierte char-Arrays. Durch wie viele Reifen muss ich denn springen, um in C Strings zu verarbeiten? _Du_ baust doch immer wieder neue Reifen auf, offenbar willst Du ja springen? Ich versuche Dir die ganze Zeit zu erklären, dass Du die Hälfte Deiner Reifen einpacken kannst. /* Int deklarieren: */ int i; /* char-Array deklarieren */ char s[16]; /* int zuweisen */ i = 0; /* String zuweisen */ strcpy (s, "String"); /* int vergleichen */ if (i == 0) ... /* String vergleichen */ if (! strcmp (s, "String")) ... Wenn Du _gesicherte_ Zuweisungen haben willst, musst Du sowohl bei numerischen als auch bei allen char-basierten Werten zusätzlichen Aufwand treiben. Jan
Moin,
* Jan Trippler
On Sam, 03 Aug 2002 at 21:33 (+0200), Thorsten Haude wrote:
* Jan Trippler
[02-08-03 20:37]: versuch[6] ist ein char-Array. Natürlich kannst Du solche char-Arrays - wenn Du es möchtest - ohne 0-Terminierung anlegen (wenn es z. B. für Flags genutzt wird, ist das auch nicht nötig), aber wenn Du _irgendeine_ Stringfunktion drauf loslassen willst, dann _muss_ am Ende eine 0 stehen.
Die ist aber schon bewußt, daß diese Dinge auch durch Fehler anderswo bzw. durch Angriffe passieren können, oder? Darum sollte C-Code idR. so robust wie möglich sein, nicht so schnell wie möglich.
Dein Aussage robust vs. schnell ist so absolut nicht richtig. Wie überall gilt auch hier: Aufwand und Nutzen müssen sich entsprechen.
Boah, wo habe ich denn gesagt, daß man unter allen Umständen, ausnahmslos und auch wenn das Leben von Millionen davon abhängt, strncmp() nutzen soll? Komm mir doch nicht mit Gemeinplätzen über Aufwand und Nutzen! Ich bleibe bei dieser Aussage: C-Code sollte idR so robust wie möglich sein, nicht so schnell wie möglich. Bitte erkläre mir, warum das "absolut nicht richtig" ist.
Es geht doch nur darum, daß diese ganze C-Eigenheit mit dem Zeiger-auf-Chararacter offensichtlich und bekannterweise nicht wasserdicht ist. Darum sollte man bei ihrer Benutzung keine Haare spalten, sondern auf Nummer sicher gehen.
Die Haarespalterei machst Du hier. Du behauptest seit Tagen, strcmp liest über die 0 hinweg und das ist Stuss.
Ich behaupte nur, daß ich nicht sicher wissen kann, daß es anders ist.
Auch das ist Stuss.
Bring Beweise statt Beleidigungen.
Du behauptest seit Tagen, dass die Benutzung von strcmp eine Sicherheitslücke ist und das ist Stuss
Ich behaupte, daß das Leben zu kurz und strncmp() zu billig ist, um darüber nachdenken zu müssen.
Das habe ich gerade in meiner Mail an Andre Heine geschrieben: Genau das *nicht darüber nachdenken* ist gefährlich.
Du vestehst das zu wörtlich. Ich kann mit den strn*-Funktionen deutlich einfacher überprüfen, ob die Speichergrenzen eingehalten werden. Ich habe auch schon strcpy() benutzt. (Panik! Entsetzen!)
Und strncmp() ist allein vielleicht billig, wenn aber mehrere zigtausend Durchläufe diesen zusätzlichen Aufwand treiben, sicher nicht mehr.
Hatte nicht jemand geschrieben, daß strncmp() in der glibc effizienter als strcmp() ist?
Das Aasen mit den zur Verfügung stehenden Ressourcen ist auch nicht gerade das Nonplusultra guter Programmierung.
Nein, da setze ich halt Prioritäten.
Kehren wir die Frage mal um: Kennst du einen strcmp(), der sich _nicht_ so vernünftig verhält?
Nein, aber das wäre nur wichtig, wenn ich alle strcmp()s kennen würde. Ich kenne aber nur einen einzigen, kann noch ein knappes halbes Dutzend durch Testprogramme testen.
Oder wie wärs mal mit ein wenig Logik? strcmp ist (neben strncmp) eine _String_-Funktion. Strings sind nullterminierte char-Arrays. Welchen Sinn sollte es für eine String-Funktion machen, einen String über seinen Terminator hinaus zu bearbeiten?
Das wäre ja sensationell, wenn es in C-Code zu Fehlern käme. Meine Güte, wie kam ich nur auf diese Idee?
Tut mir leid, ich hätte es nicht als wörtliches Zitat markieren sollen, aber wenn es keinen Typ String gibt, gibt es auch keine Strings: Gerade darum muß man ja durch so viele Reifen springen, wenn man in C Strings verarbeitet.
Auch dies ist wieder mal eine typisch Haude'sche Schlussfolgerung. Natürlich gibt es in C Strings: Das sind nullterminierte char-Arrays.
Das ist eine bloße Konvention, begründet in eben jenen Funktionen, über die wir hier sprechen. Thorsten -- Politik kann man in diesem Lande definieren als die Durchsetzung wirtschaftlicher Zwecke mit Hilfe der Gesetzgebung. - Kurt Tucholsky
Thorsten Haude
Das ist eine bloße Konvention, begründet in eben jenen Funktionen, über die wir hier sprechen.
Das ist nicht nur eine Konvention sondern wie in meiner vorherigen Mail schon geschrieben im ISO C Standard so festgelegt. Können wir nun zu etwas fruchtbareren Themen zurück kehren, bitte? Philipp -- Philipp Thomas work: pthomas@suse.de Entwicklung, SuSE Linux AG private: philippt@t-online.de
Moin,
* Philipp Thomas
Thorsten Haude
[4 Aug 2002 00:57:35 +0200]: Das ist eine bloße Konvention, begründet in eben jenen Funktionen, über die wir hier sprechen.
Das ist nicht nur eine Konvention sondern wie in meiner vorherigen Mail schon geschrieben im ISO C Standard so festgelegt.
Mir ist schon klar, daß das festgelegt ist (darum auch der Ausdruck 'Konvention'), es gibt trotzdem einen großen Unterschied zwischen einem echten Typen und einer Verabredung. Thorsten -- Der Optimist ist in der Regel ein Zeitgenosse, der ungenügend informiert ist. - John B. Priestly
Thorsten Haude
'Konvention'), es gibt trotzdem einen großen Unterschied zwischen einem echten Typen und einer Verabredung.
Natürlich gibt es den, aber so what? Was passiert denn, wenn du strncmp für die Länge einen Wert übergibst, der die des Quellarrays überschreitet? Wenn der Quellarray nicht Nullterminiert ist, liesst du irgendwann Speichermüll oder bekommst ein Speicherzugriffsfehler. Und selbst wenn du einen echten Typen hast, kann man eine Menge falsch machen, wenn man Definitionen (oder Konventionen in deiner Sprache) nicht berücksichtigt. Ich hatte letztlich den Fall, wo für eine Warenwirtschaft ein Wert von 1e-73 nicht NUll war, obwohl Epsilon für doubles 2,2e-17 ist (d.h. das zwei double Werte, deren Differenz kleiner oder gleich diesem Wert sind, als identisch zu erachten sind). Ganz abgesehen davon, das Fliesskommazahlen in einer Warenwirtschaft wenig zu suchen haben, ist es hier sträflich, *Konventionen* zu ignorieren. Könnten wir jetzt *endlich* aufhören, Haare zu spalten und uns produktiveren Dingen zuwenden? Philipp -- Philipp Thomas work: pthomas@suse.de Entwicklung, SuSE Linux AG private: philippt@t-online.de
participants (3)
-
Jan.Trippler@t-online.de
-
Philipp Thomas
-
Thorsten Haude