irgendwie sind hier schon so viele grundsätzliche gedanken/informationen geschrieben worden, dass es schade ist den thread im OT zu lassen :) ...

Tja, da ich weder Cobol noch PL/1 kenne (außer vom Namen her), kann ich nur über C und Konsorten sprechen:

Da wären dann 2 Möglichkeiten: Der Compiler trägt sorge dafür, dass jede Schreiboperation überprüft wird - das würde dann bremsen, oder der Programierer tut es, dann sind wir da wo wir jetzt sind: es schert sich (fast) keiner darum!

Ich will mal M$ einen sehr großen Teil der Schuld zuscheiben, da 1) deren Software am meisten verwndet wird (und sie somit in meinen Augen eine gewisse Verantwortung tragen) und 2) dass eben diese Software - meines Wissens nach - mit Abstand die schlechteste (Fehler & Lücken) ist.
Doch da es in der Natur von M$ liegt, eher irgendie zu funktionieren als das man es ordentlich macht, was dem Anwender etwas abverlangen würde, wird es IMHO (wie Satan sagt) noch etliche Jahre dauern, biss ich etwas ändert!

Siehst Du das wirklich so? Ist doch egal, WER die Überprüfung übernimmt: der Compiler oder der Programmierer! Denn DASS geprüft werden sollte, ist uns doch allen klar. Wenn diesen Part der Compiler übernimmt, kann ich wenigstens sicher sein, dass kein Unsinn passiert.


Ein paar Worte zu Cobol: hier ist die Speicherverwaltung komplett anders als beispielsweise in C. Der erste grundlegende Unterschied: in Cobol wird der Datenteil strikt vom Programmteil getrennt. Und sobald das Programm einen Speicherbereich außerhalb des Datenteiles ansprechen möchte (egal ob im eigenen Programm oder nicht), fliegt es mit Pauken und Trompeten raus; da habe ich gar keine Chance, irgenwohin zu tappen, wo ich nicht hintappen soll. Und weiters ist es in Cobol relativ schwierig, Datenfelder zu definieren, die eine variable Länge haben. Das hat zwar den Nachteil, dass man üblicherweise alle Variablen mit der maximalen Länge definiert, aber dafür den Vorteil, dass dann die Verwaltung im Speicher extrem effizient ist. Kommt jetzt z.B. über eine Datei ein Record daher, der größer als meine maximale interne Recordgröße ist, wird der zu lange Bereich einfach abgeschnitten. Eben auf totale Sicherheit getrimmt. So Dinge wie Pointer haben in Cobol einfach keinen Platz - das ist meiner Meinung nach nur was für technikverliebte Freaks; und es bringt für die eigentliche Lösung des Problemes (!) keinen Vorteil.


Das mit Deiner M$-Überlegung scheint korrekt zu sein. Hier hat sich - leider - das bessere Marketing durchgesetzt... :(

Ich will zwar C++ lernen (kmmt noch), hab aber schon öfters gehört, dass Pointer eine Unsitte ist, die nur die Fehlerwarscheinlichkeit nach oben treibt. Aber mal ehrlich: Wozu sotte es nützlich sein, eine Variable von 2 Seiten her anzusprechen? Ich meine wenn A auf B zeigt, dann kann ich doch gleich B stat A verwenden, oder . . ?

Aber was du da über Cobol erzählst, hört sich verdammt nach W^X an!

P.s.: Sollte ich mit meinem C++ Roman durch sein, verspreche ich dir, dass ich (hofentlich) immer abfragen werde, dass der Wert nicht zu groß für die Variable ist ;)

Wenn man vorher nicht weiß was B ist kann ich eben nur A verwenden.

Stichwort lineare Listen, binary Trees,... im Prinzip alle Dinge wo es darum geht, daß etwas auf etwas anderes verweist.
Beispiel lineare Liste: Jedes Element verweißt auf das nächste, damit lässt sich z.B. eine queue implementieren, die keine Längenbeschränkung hat und auch immer nur so viel Platz belegt wie nötig.

Und wenn du dir denkst Pointer bringen nichts, dann darfst du keine Festplatte verwenden. Die basieren darauf, daß am Anfang der Festplatte (in der FAT-File Allocation Table) ein "Pointer" auf den ersten Datenblock liegt und jeder Block auf seinen Nachfolger verweist bis die Datei komplett ist.

Und das ist nur ein kleiner Teil der Dinge die man mit Pointern so tun kann.

BTW.: Wenn du Java Programmierst arbeitest du (-fast- die "simplen" Typen wie int oder short sind Ausnahmen) nur mit Pointern, daher solltest du dir im klaren sein was passiert wenn du z.B.
Vector a=b=new Vector();
b.add("a");
machst (der Fehler ist mir vor ein paar Tagen ein bischen anders passiert).

Jak

Ja, ja, und mit 00 oder FF endet die Datei, doch DAS hat mit nem C++ Pointer (wie ich es gemeint habe) nix zu tun.

Bei der FAT zeigt jedes Fragment auf das nächset, so dass eines nach dem anderen gefunden wird. Wenn ich nicht weiß, was B ist, dann frage ich doch einfach den Inhalt von B ab, dazu brauche ich keinen Pointer!
Ich verstehe es immer noch nicht, denn wenn ich eine Variable habe, dann kann ich die auch direkt ansprechen, sollte dies nicht gehen, dann existiert sie nicht, oder ich habe eventuell nicht die Rechte dazu - wobei ich mir nicht vorstellen kann, dass mir da ein Pointer helfen wird.

Passt jetzt gerade nicht zu der Pointer Diskussion IMO trotzdem lesenswert (und sehr unterhaltsam).

http://www-aix.gsi.de/~giese/swr/index.html

Und zu dem versprechen von James020:
http://www-aix.gsi.de/~giese/swr/example01.html

Zu den Pointern:
1.) Du liest eine Datei ein. Wie kommst du an die Daten heran?
Lösung: Ein Pointer, mit dem du die Datei durchläufst, den aktuellen Wert woanders hin kopierst bzw. ihn verarbeitest und den Pointer dann weiterstellst.

2.) Situation in linearen Listen:
Du kennst das erste Element.
Jedes Element kennt seinen Nachfolger.
Wie greifst du auf das 3., 5., n-te Element zu?
Lösung Du erstellst einen neuen Pointer und setzt ihn auf das erste Element, von dort auf das nächste usw.

Jak

Jeder Compiler hat zig Flags, die irgendwelche Überprüfungen ein- oder ausschalten. Das Argument mit den Speedeinbußen gilt also nur für wenige Softwareanwendungen. Zu 486er-Zeiten lasse ich es mir noch einreden, aber nachdem heute jeder neue Office-Rechner schon 2 GHz hat kann Speed eigentlich nicht mehr das Problem sein - vor allem nicht bei so Anwendungen wie einem MP3-Player.

Für Speedfreaks könnte man dann ja eine Speedoptimierte Version anbieten, sofern ein solches Compilerflag existieren würde... bzw. die Linux-Gemeinde könnte es sich sogar selbst neu compilieren :)

Soweit ich weiß haben einige aktuelle Compiler so einen Overflow-Schutz (es wird ein "Cookie" mit der Rücksprungadresse in einen anderen Speicherbereich geschrieben, und vor dem Rücksprung überprüft, ob beide Adressen noch ident sind). Das Problem ist halt, daß man jede Software die Eingabedaten entgegennimmt mit den entsprechenden Optionen neu kompilieren müßte. Wenn der Quellcode vorhanden ist bis auf den Zeitaufwand kein Problem. Aber z.B. bei einem alten Treiber...

Jak

Hmm, interessant... im Prinzip geht es ja nicht unbedingt darum, uralte Software zu aktualisieren, sondern gängige oder zumindest zukünftige(!) Software. Und obwohl diese Exploits dauernd in den Medien sind gibt es immer wieder neue Software, die entsprechende Lücken aufweist!