Re: Was ist eine gueltige Message-ID?
Moin,
* Jan Trippler
On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:
* Bernd Brodesser
[02-08-03 10:08]: Wenn ich eine feste Länge habe, warum sollte ich dann noch dynamisch allozieren?
Um den Speicherplatz wieder freigeben zu können.
Trotzdem bleibt die Verschwendung von Speicher, weil ein #define ja den größtmöglichen Wert abbilden muss.
Ja. Ich habe nie behauptet, daß C perfekt ist.
wenn es z. B. um große Listen geht, kommt da eine Menge Holz zusammen, die auch im Zeitalter der GB-Speicher nicht zu vernachlässigen ist.
*Mir* ist klar das nicht jede Regel überall gilt.
Im Übrigen ist das Tempo in 99% der Fälle nicht so wichtig (weil eh schnell genug) wie die Sicherheit vor Bufferproblemen.
Wo hast Du _das_ denn her?
Aus der Praxis. Ist interessant da, ich kann Dir ja mal eine Karte schicken.
Nebenbei: Du betreibst Demagogie, Du behauptest nämlich implizit, dass die Verwendung von strcmp() Bufferprobleme verursacht - womit Du immer noch allein bist.
Ich behaupte nur, daß ich darüber nicht nachdenken will, und darum strncmp verwende, wenn es sich irgendwie einrichten läßt.
Wenn es nur ein einziger, oder wenige Vergleiche sind, so ist das sicherlich egal. Aber gerade Vergleiche können sehr, sehr häufig vorkommen. Denk mal an Sortierprogramme.
Mache ich nicht, weil man in dem Fall die Strings von Anfang an anders verwalten kann.
Wie?
Ich habe mich schlecht ausgedrückt: Man kann in diesem Fall mit anderen Methoden sicherstellen, das es keine Probleme mit überschrittenen Buffergrenzen gibt.
Das willst du alles hart kodiert in das Programm schreiben? Wie flexibel und gut wartbar ;-)
Dafür gibt's #defines.
Der Wert wird beim Compelieren festgelegt. Was ist, wenn ein und die Gleiche Funktion von verschiedene Programmteile benutzt wird, die ganz unterschiedliche Längen haben?
Dann wird die Länge mit übergeben.
Und wieder ein Parameter mehr, der den Stack belastet und zur potenziellen Fehlerquelle wird (short - int - long - unsigned - 32 Bit - 64 Bit, ...) - und der natürlich in den Funktionen ebenfalls zu größerer Komplexität führt.
Du liebe Güte, Du hörst sich an, also würdest Du C und Ruby ein wenig durcheinanderbringen. Ja, in C muß man gelegentlich Dinge tun, die etwas unhandlich sind. Das liegt daran, daß die Sprache auf einer niedrigen Ebene funktioniert und (aufgepaßt:) keinen Stringtyp kennt. Ich habe wie gesagt die meiste Erfahrung mit einem einzigen Programm (NEdit) gemacht, und darum auch nur mit einer relativ kleinen Gruppe von Lehrern/Mitentwicklern. Vielleicht hast Du ja Beispiele aus einem anderen Programm, wie man mit Strings umgeht? Ich lerne immer gerne dazu, besonders in diesem Zusammenhang. Thorsten -- The privacy of correspondence, posts and telecommunications shall be inviolable. - German Grundgesetz, Article 10, Sec. 1
Moin Moin, Am Samstag, 3. August 2002 20:24 schrieb Thorsten Haude:
* Jan Trippler
[02-08-03 17:06]: On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:
[...] Ich linke mich jetzt mal dazu :))
Nebenbei: Du betreibst Demagogie, Du behauptest nämlich implizit, dass die Verwendung von strcmp() Bufferprobleme verursacht - womit Du immer noch allein bist.
IMHO sollte man bei C99 lieber strncmp, strncat, strncpy, usw. verwenden. Sorry, ich kenne leider den ganzen Thread nicht. Durch strcmp() können IMHO Puffer Überläufe passieren, man sollte gerade bei der string Verarbeitung aufpassen. Jedenfalls wenn man mit Sockets arbeitet, ein Server kann einem soetwas sehr übel nehmen. ZITAT: "Es ist bemerkenswert, wie viele Einbrüche durch einen Hacker zustande kamen, der so viele Daten sendete, daß der Server-Aufruf von sprintf Puffer zum Überlaufen brachte. Weitere Funktionen, mit denen wir vorsichtig sein sollten, sind gets, strcat,strcpy. Statt dessen sollten wir üblicherweise fgets, strncat und strncpy verwenden. Zusätzliche Hinweise zum Aufbau von sicheren Netzwerkenprogrammen finden Sie im Kapitel 23 von[Garfinkel und Spafford 1996]" Aus dem Buch "Programmieren von UNIX-Netzwerken", Hanser Verlag. IMHO ist das genauso mit strcmp(), mag mich aber täuschen...
Ich behaupte nur, daß ich darüber nicht nachdenken will, und darum strncmp verwende, wenn es sich irgendwie einrichten läßt.
ACK.
Wenn es nur ein einziger, oder wenige Vergleiche sind, so ist das sicherlich egal. Aber gerade Vergleiche können sehr, sehr häufig vorkommen. Denk mal an Sortierprogramme.
Server z.B., DOS Attacken, etc... Grüße Andre
On Sam, 03 Aug 2002 at 20:49 (+0200), Andre Heine wrote:
Am Samstag, 3. August 2002 20:24 schrieb Thorsten Haude:
* Jan Trippler
[02-08-03 17:06]: On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:
[...] Ich linke mich jetzt mal dazu :))
Nebenbei: Du betreibst Demagogie, Du behauptest nämlich implizit, dass die Verwendung von strcmp() Bufferprobleme verursacht - womit Du immer noch allein bist.
IMHO sollte man bei C99 lieber strncmp, strncat, strncpy, usw. verwenden.
Sorry, ich kenne leider den ganzen Thread nicht. Durch strcmp() können IMHO Puffer Überläufe passieren, man sollte gerade bei der string Verarbeitung aufpassen.
Sorry, das sind Gemeinplätze. Schau Dir den Anfang des Threads an, damit Du verstehst, wie diese Diskussion zustande kam. BTW: man sollte bei der Programmierung immer aufpassen - nicht nur bei Strings (um auch mal einen Gemeinplatz beizusteuern).
Jedenfalls wenn man mit Sockets arbeitet, ein Server kann einem soetwas sehr übel nehmen.
JEDES Programm nimmt Buffer Overflows übel. Es führt in den meisten Fällen zu einer ungewollten Programmfortführung (oder -beendigung).
ZITAT: "Es ist bemerkenswert, wie viele Einbrüche durch einen Hacker zustande kamen, der so viele Daten sendete, daß der Server-Aufruf von sprintf Puffer zum Überlaufen brachte. Weitere Funktionen, mit denen wir vorsichtig sein sollten, sind gets, strcat,strcpy. Statt dessen sollten wir üblicherweise fgets, strncat und strncpy verwenden. Zusätzliche Hinweise zum Aufbau von sicheren Netzwerkenprogrammen finden Sie im Kapitel 23 von[Garfinkel und Spafford 1996]"
Aus dem Buch "Programmieren von UNIX-Netzwerken", Hanser Verlag.
Was meinst Du, warum strcmp in diesem Zitat nicht auftaucht ... Zu dem Zitat: Es geht hier IMHO um eine bestimmte Art von Stringhandling: Die Zuweisung von Werten unbekannter Herkunft an einen String. Alle diese Funktionen haben gemeinsam, dass sie die Quell-Strings ungeprüft (bis zum ersten auftretenden 0 - sic!) an das Ziel übergeben. Es wird keine Prüfung durchgeführt, ob die Deklaration des Zielpuffers ausreichend ist - das geht aus 2 Gründen nicht: - die aufgerufene Funktion kennt die Deklaration nicht (sie kriegt einen Pointer als Parameter) - die Größe kann zur Compile-Zeit unbekannt sein (dynamische Puffer). Der Buffer Overflow tritt aus genau einem Grund auf: Der Programmierer hat einen String aus unsicherer Quelle nicht ausreichend geprüft. Wenn das geschieht, kann man diese Funktionen auch einsetzen. Ein Schutz kann u. a. mit Hilfe von strncat, strncpy, fgets passieren, die eine Maximallänge zu kopierender Zeichen erwarten; denkbar sind aber auch Konstrukte wie: while (i < sizeof buf) *(buf + i++) = fgetc(file); oder: sprintf (format, "%%-.%ds", sizoef (buf) - 1); sprintf (buf, format, eingabe); oder: ...
IMHO ist das genauso mit strcmp(), mag mich aber täuschen...
Was bringt Dich auf diesen Gedanken? Alle im Zitat genannten Funktionen weisen Strings Werte zu, str(n)cmp vergleicht Strings. strcmp ist nur dann ein Risiko, wenn einer der beiden Parameter nicht sauber nullterminiert ist. Und dann kann strcmp eben einfach durch den Speicher sausen und bei der ersten Unstimmigkeit (oder 0!) anhalten. Wenn ich ein Programm baue, dem erst an dieser Stelle auffällt, das da was nicht stimmen könnte - ... Zum x-ten Mal: Die Diskussion begann, als Thorsten Haude behauptete, man könne sich nicht sicher sein, ob strcmp() am Stringende (Wert des Bytes = 0) aufhört zu vergleichen - und das ist nun mal Quatsch!
Ich behaupte nur, daß ich darüber nicht nachdenken will, und darum strncmp verwende, wenn es sich irgendwie einrichten läßt.
ACK.
NACK! Wenn ich anfange, in Programmen nicht mehr über die Zweckmäßigkeit dieser (strcmp) oder jener (strncmp) Funktion nachzudenken, dann sollte ich mir einen anderen Job suchen. Wie im Thread bereits mehrmals erwähnt bedeutet der Einsatz von strncmp immer, dass ich mir Gedanken darüber machen muss, wie weit ich den Vergleich laufen lasse. Das kann einfach sein (statische Strings, wohldefinierte Größen), kann aber im Falle von dynamisch erzeugten Strings auch ziemlich aufwändig werden - vor allem dann, wenn ich diese Berechnung sehr oft machen muss.
Wenn es nur ein einziger, oder wenige Vergleiche sind, so ist das sicherlich egal. Aber gerade Vergleiche können sehr, sehr häufig vorkommen. Denk mal an Sortierprogramme.
Server z.B., DOS Attacken, etc...
Was sollen uns diese Begriffe jetzt sagen? Jan
On Sat, 03 Aug 2002 at 22:43 (+0200), Jan Trippler wrote:
On Sam, 03 Aug 2002 at 20:49 (+0200), Andre Heine wrote:
Am Samstag, 3. August 2002 20:24 schrieb Thorsten Haude:
* Jan Trippler
[02-08-03 17:06]: On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:
[...] Ich linke mich jetzt mal dazu :)) [...]
Könntet ihr vielleicht aufhören, eine Diskussion parallel über zwei Listen zu führen (suse-programming, suse-linux)? Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ "Mit dem Geist ist es wie mit dem Magen: Man kann ihm nur Dinge zumuten, die er verdauen kann." -- Winston Churchill
On Sam, 03 Aug 2002 at 23:27 (+0200), Bernhard Walle wrote:
On Sat, 03 Aug 2002 at 22:43 (+0200), Jan Trippler wrote:
On Sam, 03 Aug 2002 at 20:49 (+0200), Andre Heine wrote:
Am Samstag, 3. August 2002 20:24 schrieb Thorsten Haude:
* Jan Trippler
[02-08-03 17:06]: On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:
[...] Ich linke mich jetzt mal dazu :)) [...]
Könntet ihr vielleicht aufhören, eine Diskussion parallel über zwei Listen zu führen (suse-programming, suse-linux)?
Sorry, ich habe die doppelten Einträge im To nicht gesehen, sonst hätte ich suse-programming gelöscht - für mich ist der Thread aber eh beendet. Deshalb nochmal an beide Listen. Jan
Hi Jan, Am Samstag, 3. August 2002 22:43 schrieb Jan Trippler:
On Sam, 03 Aug 2002 at 20:49 (+0200), Andre Heine wrote: Sorry, das sind Gemeinplätze. Schau Dir den Anfang des Threads an, damit Du verstehst, wie diese Diskussion zustande kam. BTW: man sollte bei der Programmierung immer aufpassen - nicht nur bei Strings (um auch mal einen Gemeinplatz beizusteuern).
Jedenfalls wenn man mit Sockets arbeitet, ein Server kann einem soetwas sehr übel nehmen.
JEDES Programm nimmt Buffer Overflows übel. Es führt in den meisten Fällen zu einer ungewollten Programmfortführung (oder -beendigung).
Na ja, eigentlich wird dem Server nur der Platz geklaut :)) Ich meine RAM damit... Die Gefahr eines Puffer Überlauf bekommst Du im Internet z.B. schneller zu spüren als in Deiner FIRMA... Oder habt Ihr nur Hacker angestellt :))))))
ZITAT: "Es ist bemerkenswert, wie viele Einbrüche durch einen Hacker zustande kamen, der so viele Daten sendete, daß der Server-Aufruf von sprintf Puffer zum Überlaufen brachte. Weitere Funktionen, mit denen wir vorsichtig sein sollten, sind gets, strcat,strcpy. Statt dessen sollten wir üblicherweise fgets, strncat und strncpy verwenden. Zusätzliche Hinweise zum Aufbau von sicheren Netzwerkenprogrammen finden Sie im Kapitel 23 von[Garfinkel und Spafford 1996]"
Aus dem Buch "Programmieren von UNIX-Netzwerken", Hanser Verlag.
Was meinst Du, warum strcmp in diesem Zitat nicht auftaucht ...
Ja, Du kannst Recht haben...
Zu dem Zitat: Es geht hier IMHO um eine bestimmte Art von Stringhandling: Die Zuweisung von Werten unbekannter Herkunft an einen String. Alle diese Funktionen haben gemeinsam, dass sie die
Ja da hast Du, vertraue nie einen fremden String!
IMHO ist das genauso mit strcmp(), mag mich aber täuschen...
Was bringt Dich auf diesen Gedanken? Alle im Zitat genannten
Das "n"! Sorry, aber das "n" macht mir diese Gedanken :)) Und "Programmieren von UNIX-Netzwerken"... Warum gibt es str_n_cmp(9 überhaupt? Ich denke weil es sicherer ist! Täusche ich mich? Ich habe angenommen (kenne den Thread nicht, SORRY), daß Ihr über den Sinn von strncmp() redet. IMHO geht die Verwendung von strncmp() auch auf Puffe Überläufe zurück. (Reine Vermutung...)
Funktionen weisen Strings Werte zu, str(n)cmp vergleicht Strings. strcmp ist nur dann ein Risiko, wenn einer der beiden Parameter nicht sauber nullterminiert ist. Und dann kann strcmp eben
Aber ein Risiko, oder habe ich Dich missverstanden?
einfach durch den Speicher sausen und bei der ersten
Das ist doch bestimmt nicht nett, oder? Du hast ja Recht, man überprüft den String schon vorher...
Zum x-ten Mal: Die Diskussion begann, als Thorsten Haude behauptete, man könne sich nicht sicher sein, ob strcmp() am Stringende (Wert des Bytes = 0) aufhört zu vergleichen - und das ist nun mal Quatsch!
Wieder Sorry, habe ich nicht gelesen. Die "n" haben trotzalledem etwas zu bedeuten.. Oder ist das "n" nur Schikane? Ich habe mir die Frage gestellt, warum macht man ein Funktion "strncmp()"? Weil Sie Fehler von strcmp() ausgleichen soll? So ist bis jetzt mein Gedankengang... Ciao Andre PS: Suche mir deswegen keinen neuen JOB...
On Son, 04 Aug 2002 at 03:23 (+0200), Andre Heine wrote: [...]
Oder ist das "n" nur Schikane? Ich habe mir die Frage gestellt, warum macht man ein Funktion "strncmp()"? Weil Sie Fehler von strcmp() ausgleichen soll?
Weil man ab und zu nur n Zeichen eines String überprüfen möchte? Jan
On Sam, 03 Aug 2002 at 20:24 (+0200), Thorsten Haude wrote:
* Jan Trippler
[02-08-03 17:06]: On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote: [...]
Im Übrigen ist das Tempo in 99% der Fälle nicht so wichtig (weil eh schnell genug) wie die Sicherheit vor Bufferproblemen.
Wo hast Du _das_ denn her?
Aus der Praxis. Ist interessant da, ich kann Dir ja mal eine Karte schicken.
1 Karte = 99% der Fälle? Diese Art der Analyse solltest du mal der GFK zukommen lassen, die machen das IMHO ähnlich ;-) [Länge als Parameter]
Und wieder ein Parameter mehr, der den Stack belastet und zur potenziellen Fehlerquelle wird (short - int - long - unsigned - 32 Bit - 64 Bit, ...) - und der natürlich in den Funktionen ebenfalls zu größerer Komplexität führt.
Du liebe Güte, Du hörst sich an, also würdest Du C und Ruby ein wenig durcheinanderbringen. Ja, in C muß man gelegentlich Dinge tun, die etwas unhandlich sind. Das liegt daran, daß die Sprache auf einer niedrigen Ebene funktioniert und (aufgepaßt:) keinen Stringtyp kennt.
??? Ich kenne Ruby nicht, kann da also mitnichten was durcheinander bringen. Das bezog sich pur auf C. Ich entnehme Deinem letzten Satz, dass Du endlich meine andere Mail verstanden hast? BTW: In jeder Programmiersprache muss man IMHO abhängig von der Problemstellung kompromisse eingehen. Es gibt keine für alle Themen ideale Sprache. String-Verarbeitung - wenn sie denn nicht kombiniert mit systemnahen Funktionen auftritt - würde ich freiwillig nie mit C realisieren - dafür gibts Perl :-)
Ich habe wie gesagt die meiste Erfahrung mit einem einzigen Programm (NEdit) gemacht, und darum auch nur mit einer relativ kleinen Gruppe von Lehrern/Mitentwicklern. Vielleicht hast Du ja Beispiele aus einem anderen Programm, wie man mit Strings umgeht? Ich lerne immer gerne dazu, besonders in diesem Zusammenhang.
Ja, habe ich - aber die meisten davon gehören meinen Kunden. Jan
participants (4)
-
Andre Heine
-
Bernhard Walle
-
Jan.Trippler@t-online.de
-
Thorsten Haude