C/C++ Forum :: Frage zu cin

Unregistrierter

Warum funktioniert das?

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	1 2 3 4 5 6 7 8 9 10	int main() { char lBuf[2]; while(true) { cout << ">"; cin >> lBuf; cout << lBuf << endl; } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	int main() { char lBuf[2]; while(true) { cout << ">"; cin >> lBuf; cout << lBuf << endl; } }

C/C++ Code:
1 2 3 4 5 6 7 8 9 10	int main() { char lBuf[2]; while(true) { cout << ">"; cin >> lBuf; cout << lBuf << endl; } }

Ist sowas legitim? Oder ruft das Fehler hervor? (vermute ich jetzt mal)
Würde es halt gerne verstehen

SeppJ Moderator 22:56:30 07.09.2010 Titel:

Kannst du sagen, was du daran nicht verstehst? Ich muss erst neuen Kaffeesatz aufsetzen, bevor ich wieder Wahrsagen kann.

Der Code provoziert übrigens Fehler, wenn zwei oder mehr Nicht-Whitespace-Zeichen nacheinander eingegeben werden.

Unregistrierter

Das stimmt nicht, habe es gerade probiert und es wird kein Fehler produziert. So was nennt sich dann bloß undefiniertes Verhalten das nur fehleranfällig ist aber logisch gesehen ist der Code fehlerfrei und produziert auch nicht immer einen Fehler bei mehr als 2 Zeichen.

Bitte nicht schreiben wenn man es nicht wirklich verstanden hat, danke.

SeppJ Moderator 23:03:25 07.09.2010 Titel:

fr33g Mitglied 23:23:56 07.09.2010 Titel:

nööööö schrieb:

...So was nennt sich dann bloß undefiniertes Verhalten das nur fehleranfällig ist...

Der Satz ist ja mal geil, les dir den nochmal durch

Ist ja nicht so, als wäre undefiniertes Verhalten allein schon ein Fehler

Lg freeG

HAWXthy Mitglied 16:51:56 08.09.2010 Titel:

Kommt darauf an mit welchem Compiler du den Code compilierst, weil nicht jeder Compiler comipliert eine function die etwas zurück geben soll, dies jedoch nicht tut (return 0; in dem fall).
Das Porgramm ansich sollte funktionieren bis auf die Tatsache das nur maximal 2 chars in dein array eingelesen werden können und das ganze in einer Endloseschleife läuft.

Michael E. Mitglied 16:57:30 08.09.2010 Titel:

HAWXthy schrieb:

Kommt darauf an mit welchem Compiler du den Code compilierst, weil nicht jeder Compiler comipliert eine function die etwas zurück geben soll, dies jedoch nicht tut (return 0; in dem fall).

Für main ists laut Standard erlaubt.

asc Mitglied 16:58:10 08.09.2010 Titel:

HAWXthy schrieb:

...weil nicht jeder Compiler comipliert eine function die etwas zurück geben soll, dies jedoch nicht tut (return 0; in dem fall).

int main ist eine Ausnahme. int main gibt, wenn man kein explizites return angibt, ein return 0 zurück.

SeppJ Moderator 16:58:20 08.09.2010 Titel:

HAWXthy schrieb:

Kommt darauf an mit welchem Compiler du den Code compilierst, weil nicht jeder Compiler comipliert eine function die etwas zurück geben soll, dies jedoch nicht tut (return 0; in dem fall).

In C++ ist die main-Funktion eine Ausnahme. Die gibt automatisch 0 zurück, wenn man nichts hinschreibt.

Zitat:

Das Porgramm ansich sollte funktionieren bis auf die Tatsache das nur maximal 2 chars in dein array eingelesen werden können und das ganze in einer Endloseschleife läuft.

Naja, man sollte aber noch erwähnen, dass vom istream bei der Operation auch noch ein Nullzeichen angehängt wird. Das muss auch noch in das Array passen (sonst wird es einfach dahinter geschrieben, wodurch wer weiß was überschrieben wird), also hat man effektiv nur Platz für ein eingegebenes Zeichen.

SeppJ Moderator 16:58:20 08.09.2010 Titel:

edit: Doppelpost

Biolunar Moderator 17:00:38 08.09.2010 Titel:

Das Programm ist jawohl definitiv fehlerhaft! Woher soll cin wissen wie viele chars es in das Array schreiben darf? Wenn ich jetzt 3 Zeichen eingebe, dann wird cin auch 3 Zeichen schreiben, also gibt es einen buffer overflow :live:

. Verhindern könnte man das in diesem Fall indem man std::ios_base::width() verwendet (oder std::setw()).

SeppJ Moderator 17:11:41 08.09.2010 Titel:

Oder std::string

Unregistrierter

Vielleicht habe ich mich etwas unverständlich ausgedrückt,
probiert den Code doch bitte mal aus.

Hier wird devinitiv KEIN Fehler produziert. (Zummindest auf den 1. Blick nicht)
Egal ob man jetzt 5 oder 500 oder auch 5000 Zeichen eingibt,
bis jetzt gabs keine Speicherfehler oder sonst was.

Eine Begründung wäre dass cin >> einfach über die array Grenzen
hinaus schreibt, jedoch in dem Fall nichts "wichtiges" überschreibt.

Interessant ist halt immer noch dass ich es bis jetzt nicht geschafft
habe einen Fehler zu produzieren, egal wie viele Zeichen ich eingegeben
habe.

Unregistrierter

Du nutzt Microsoft Visual C++? Eventuell handelt es sich auch um ein Compiler Bug.

C/C++ Code:
int main() { char buf[1]; buf[200] = 10; }

C/C++ Code:
int main() { char buf[1]; buf[200] = 10; }

C/C++ Code:
int main() { char buf[1]; buf[200] = 10; }

Funktioniert. Kein Absturz. :die:

C/C++ Code:
int main() { int buf[1]; buf[200] = 10; }

C/C++ Code:
int main() { int buf[1]; buf[200] = 10; }

C/C++ Code:
int main() { int buf[1]; buf[200] = 10; }

Funktioniert nicht. Absturz. :live:

Eine Erklärung dafür habe ich jedenfalls nicht.

asc Mitglied 20:05:24 08.09.2010 Titel:

--- schrieb:

Du nutzt Microsoft Visual C++? Eventuell handelt es sich auch um ein Compiler Bug...

Nein, da es undefiniertes Verhalten ist, kann alles passieren (von nichts sichtbaren, bis zur Access Violation, dem Toasten deiner Festplatte...). Dies ist kein Compilerfehler, sondern beruht auf dem Designprinzip von C und C++.

Das ist genauso wie mit dem std::vector, der einmal den Indexoperator anbietet, und einmal die at-Methode. Die at-Methode prüft einen unerlaubten Indexzugriff, der Indexoperator muss dies aber nicht tun (und in den meisten Implementierungen die ich kenne, ist er auch ungeprüft).

C und C++ sind auf Performance ausgelegt, Prüfungen sind in der Regel optional (Wenn man dauernd durch riesige Arrays geht, macht sich eine Prüfung bei jeden Zugriff durchaus bemerkbar).

Unregistrierter

Den ersten Code habe ich auch mit dem g++ kompiliert und da gibt es keinen Fehler. Auch ein mehrmaliges Ausprobieren mit mehreren Zeichen konnte dem Programm keinen Fehler entlocken, irgendwann wird da sicherlich mal was überschrieben aber der Code an sich ist nicht fehlerhaft sondern nur fehleranfällig.

Unregistrierter

Das Verhalten ist undefiniert. Der C++-Standard definiert nicht, was in solchen Fällen passieren sollte, und sofern dein Compiler dafür keine eigene Semantik definiert (was er nicht tut), öffnest du dich damit für Merkwürdigkeiten aller Art.

Du schreibst in Speicher, der dir nicht gehört. Was dort liegt? Wer weiß - das wird von Compiler zu Compiler und von Betriebssystem zu Betriebssystem anders sein, und unter Umständen auch von Programmdurchlauf zu Programmdurchlauf. Es kann dir passieren, dass du einen Segfault bekommst. Es kann passieren, dass andere Variablen auf einmal merkwürdige Werte haben. Es kann dir passieren, dass du nach Beendigung der Funktion nicht an die aufrufende Stelle zurückkommst. Es kann dir passieren, dass ein nachfolgender Aufruf einer anderen Funktion sich seltsam verhält, dir beispielsweise die Festplatte formatiert.

Selbstverständlich ist so was fehlerhaft, und je eher du das in deinen Schädel kriegst, desto besser für dich und alle, die deine Programme benutzen wollen. Du kannst doch kein Programm so entwickeln, dass es vielleicht ab und zu das macht, was es soll.

Als nächstes behauptest du noch, ein Auto mit kaputter Bremsleitung sei nicht kaputt, sondern lediglich unfallanfällig.

Unregistrierter

Wie die viele Meldungen über Programmfehler aufzeigen, zeigen so gut wie alle C++ Programme undefiniertes Verhalten. Eine sichere C++ Anwendung mit definiertem Verhalten schaffen nicht mal die großen der Großen zu entwickeln und erst recht keiner hier im Forum.

asc Mitglied 20:57:01 08.09.2010 Titel:

defrgthz schrieb:

Wie die viele Meldungen über Programmfehler aufzeigen, zeigen so gut wie alle C++ Programme undefiniertes Verhalten.

Was für ein Schwachsinn. Fehler der Programmierer auf die Sprache zu schieben, ist jedenfalls nonsense. Sowohl C als auch C++ sind systemnahe Sprachen, und als solche dürfen sie eigentlich nicht zusätzliche Performace für Prüfungen die in vielen Fällen unnötig sind verlangen.

Wieso sollte beispielsweise bei jedem Zugriff der Index geprüft werden, wenn man in der Regel bereits von der Programmierseite einen fehlerhaften Indexzugriff ausschließen kann.

In C als auch C++ bezahlt man nur für das, was man auch will. Wenn man eine Indexüberprüfung braucht, schreibt man sich entweder eine, oder nimmt geprüfte Zugriffsmethoden (wie z.B. at() beim std::vector). Zudem ist ein std::string deutlich eher für cin-Eingaben unbekannter Größe geeignet als ein char-Array. Wenn man unbedingt mit char-Arrays arbeiten will soll man gefälligst auch die C-Methoden, ggf. die mit Indexprüfung verwenden.

defrgthz schrieb:

Eine sichere C++ Anwendung mit definiertem Verhalten schaffen nicht mal die großen der Großen zu entwickeln und erst recht keiner hier im Forum.

Wenn du Programmierfehler als Sprachfehler hinstellst, wird KEIN Programmierer eine Anwendung mit definierten Verhalten schaffen (Und auch Sprachen die Indexprüfungen durchführen, schützen nicht zwangsweise vor Fehlern. Beispiel NullPointerExceptions in Java-Programmen). Davon abgesehen das es Statistiken gibt das ungefähr 5% aller Codezeilen Fehler enthalten.

Unregistrierter

Wie du schon geschrieben hast sind ca. 5% eines jeden Programmcodes fehlerhaft. Nur ist das Problem bei C++ das hier die Fehler sehr üble Folgen haben können während sich bei Sprachen wie z.B. Java/C#/Python der Schaden meist nicht gleich in einem BufferOverflow bemerkbar macht.

Versteht du was ich damit sagen will?

Ich liebe die Systemsprachen auch über alles aber vom Sicherheitsaspekt sind sie Schrott. Da kannst du versuchen dich an alle Regel der Welt zu halten deine Anwedung wird fehlerhaft sein und bei C++ kann das ganz übel sein.

Aber so zum rumspielen mag ich die Sprache auch sehr, ist eine echte Herausforderung für jeden Programmierer.

asc Mitglied 21:40:19 08.09.2010 Titel:

efddfsfsdf schrieb:

Wie du schon geschrieben hast sind ca. 5% eines jeden Programmcodes fehlerhaft. Nur ist das Problem bei C++ das hier die Fehler sehr üble Folgen haben können während sich bei Sprachen wie z.B. Java/C#/Python der Schaden meist nicht gleich in einem BufferOverflow bemerkbar macht.

Ich halte einen Absturz teilweise für weniger schlimm, als ein unentdeckten Logikfehler, der z.B. Finanzbeträge verfälscht.

Ganz davon abgesehen habe ich bislang aus mehreren Projekten nicht feststellen können das C++ Programme schlimmere Fehler als beispielsweise Java- oder C#-Programme haben. Teilweise waren letztere sogar viel problematischer weil die Programmierer sich zu sehr auf die "Fehlerkorrektur" der Sprache verlassen haben.

efddfsfsdf schrieb:

Ich liebe die Systemsprachen auch über alles aber vom Sicherheitsaspekt sind sie Schrott. Da kannst du versuchen dich an alle Regel der Welt zu halten deine Anwedung wird fehlerhaft sein und bei C++ kann das ganz übel sein.

Ich sehe bei C++ kein Problem wegen Sicherheitsaspekten. Wo ich sie brauche, setze ich den entsprechenden Overhead für die Prüfungen ein. Und die Probleme des OP habe ich in dem Stil garnicht, da ich Rohe Arrays ohnehin vermeide, und bei unbekannten Datenmengen entweder sicherstelle das die Eingabe nach einer begrenzen Eingabemenge abbricht (sprich sich an den Grenzen orientiert), oder das die Datenstruktur entsprechen mitwachsen kann.

efddfsfsdf schrieb:

Aber so zum rumspielen mag ich die Sprache auch sehr, ist eine echte Herausforderung für jeden Programmierer.

Sie ist keine Herausforderung, verlangt aber wie jede Systemsprache, das man sich auf einer niedrigeren Ebene um die Behandlung kümmern muss, oder entsprechend eine Schicht darüber setzt. Die ersten Java-VMs waren intern häufig mit C++ geschrieben, nur wurden halt zwischen dem Entwickler und dem System noch Schichten eingezogen.

Unregistrierter

Du würdest im Ernst sicherheitsrelevante Software lieber in einer Systemsprache dem Kunden empfehlen? E-Commerce, Krankenhaus, Banken, Raumfahrt, Militär, Behörden?

Auweia, zum Glück denken da viele anderes.

Unregistrierter

Zunächst mal möchte ich diese Statistiken sehen, und ich möchte sehen wie und auf welcher Datenbasis sie erhoben werden. Einen Mechanismus, Codezeilen zu identifizieren, die Fehler verursachen, fände ich außerordentlich praktisch. Obwohl ich meine Zweifel habe, wie sinnvoll es ist, Fehler in Zeilen zu messen - das ist schon für Codekomplexität eine ausgesprochen unbrauchbare Metrik, und Fehler entstehen häufig durch das Zusammenspiel verschiedener Codeteile, die für sich allein genommen durchaus korrekt sein können. Außerdem stellt sich die Frage, welche Programme dafür herangezogen werden; es ist beispielsweise davon auszugehen, dass du in Tutorials im Internet eine bedeutend höhere Quote verbuggter Software finden wirst als in Produktionscode.

Was die genannten Anwendungsfälle angeht:

Zu Krankenhäusern kann ich nicht viel sagen. Nach allem was ich höre, wird da viel in MUMPS gemacht.

In Behörden gibt es viele verschiedene Anwendungen, für die im Einzelfall das sinnvollste Werkzeug ausgewählt werden muss, generell reden wir hier aber hauptsächlich von alltäglicher Office-Software (Word, Excel etc.). Du kannst davon ausgehen, dass alles, was in einer Behörde verwendet werden soll, ohne großen Aufwand an solche Systeme anbindbar sein muss, und niemand schreibt Excel-Add-Ins in Java. Es sollte mich nicht wundern, wenn ein großer Teil dort verwendeter Software vom Sachbearbeiter selbst in Visual Basic zusammengeklickt wäre. Im Übrigen sei noch angemerkt, dass der Client für Phase 2 von ELSTER in ANSI-C entwickelt wird.

Bei Raumfahrt und Militär reden wir zu einem großen Teil von Embedded-Geräten; es sollte mich wundern, wenn da viele virtuelle Maschinen zum Einsatz kämen. Aller Wahrscheinlichkeit nach wirst du da viel C finden, und speziell in der Raumfahrt wohl auch einiges an FORTRAN.

Bei Banken kann ich dir sicher sagen, dass jede Mikrosekunde aus der Software rausgequetscht werden muss; in einer Zeit automatisierter Handelssysteme wäre alles andere ein großer Wettbewerbsnachteil. Auch sind in die Zusammenhänge in Kreditderivaten oft so komplex, dass du um eine Monte-Carlo-Simulation nicht herum kommst, und ob der (unter großer Anspannung stehende) Händler eine Minute oder eine halbe auf sein Ergebnis warten muss, macht in der Tat einen Unterschied. Selbstverständlich fängt man solche Dinge nah an der Maschine an.

Damit ist nicht gesagt, dass in diesen Bereichen nur Systemsprachen zum Einsatz kommen oder kommen sollten (das wäre unwahr), aber maschinennahe Sprachen kategorisch auszuschließen, kann sich niemand erlauben.

Davon unabhängig hat asc recht, dass Logikfehler das größere Problem sind - frag nur das Mars Climate Orbiter-Team der NASA. Oder die NYSE. Bei sicherheitsrelevanter Software ist vor allem wichtig, kompetente Entwickler zu finden und die Software ausgiebig zu testen (was kompetente Entwickler eh tun). Die Sprachwahl ist sekundär.

Unregistrierter

Einen Logikfehler schlimmer einzustufen als einen Buffer-Overflow halte ich für grob fahrlässig in einer Beratung. Wie hier schon beschrieben kann ein BO einfach mal einen Variabelinhalt verändern oder eine falsche Funktion aufrufen. Der berühmte Absturz wäre der Fall mit dem wenigsten Schaden.

Wenn Logikfehler eh immer vorkommen dann kommen diese ja bei den Systemsprache noch dazu, also haben wir es hier mit Logik- und Speicherfehlern zu tun.

Ich glaube mehr brauch man nicht sagen, es läuft darauf hinaus das man eine viel höheren Arbeitsaufwand hat wenn man eine Anwendung in einer Systemsprache erstellt. Wenn es nicht anders geht ok, aber sobald man eine Wahl hat wird diese mit Sicherheit heutzutage nicht mehr zugunsten eine Systemsprache ausfallen.

asc Mitglied 11:11:11 09.09.2010 Titel:

Vorsicht! schrieb:

Einen Logikfehler schlimmer einzustufen als einen Buffer-Overflow halte ich für grob fahrlässig in einer Beratung.

1. Sind Bufferoverflows nicht so häufig wie hier gerne dargestellt werden, und man muss teilweise sogar absichtlich unsinnige Konstrukte dafür benutzen. Wer fixe Datenstrukturen für Eingaben undefinierter Länge einsetzt, ist mit jemanden vergleichbar, der Säure in ungekennzeichneten, öffentlich zugänglichen Gefäßen aufbewahrt.

2. Sind Zugriffsverletzungen (damit meine ich nicht nur Bufferoverflows) auch nicht so häufig, und nicht selten durch ebensolche Konstrukte, die man ohne weiteres meiden kann.

Auch in anderen Branchen gibt es Sicherheitsregeln bei deren Missachtung eine grobe Fahrlässigkeit darstellt. Systemsprachen ermöglichen zwar deutlich leichter einen Missbrauch, man kann sie aber grundsätzlich auch sehr sicher einsetzen. In anderen Sprachen muss man durchaus auch Regeln einhalten (z.B. in Sprachen, in denen Referenzen intern Zeiger sind die null annehmen können, hat man an Stellen, die nicht im Kontrollbereich liegen, auch eine Nullprüfung durchzuführen [z.B. würde ich bei privaten Methoden, die durch die Aufrufe null schon ausschließt, nicht Zwangsweise eine null-Prüfung der Parameter durchführen, bei einer öffentlichen schon]).

Vorsicht! schrieb:

Wenn Logikfehler eh immer vorkommen dann kommen diese ja bei den Systemsprache noch dazu, also haben wir es hier mit Logik- und Speicherfehlern zu tun.

Deren Gefahrenquelle man aber durchaus bereits durch eine entsprechende Programmierweise massiv einschränken kann.

Vorsicht! schrieb:

Ich glaube mehr brauch man nicht sagen, es läuft darauf hinaus das man eine viel höheren Arbeitsaufwand hat wenn man eine Anwendung in einer Systemsprache erstellt.

Aber nicht zwangsweise der Sicherheit wegen, sondern aufgrund des Schreibaufwandes (Was aber auch nicht zwangsweise stimmen muss, so können C++ Templates durchaus auch etliches an Schreibaufwand reduzieren).

Vorsicht! schrieb:

Wenn es nicht anders geht ok, aber sobald man eine Wahl hat wird diese mit Sicherheit heutzutage nicht mehr zugunsten eine Systemsprache ausfallen.

Wer sinnvoll auswählt, wird die Werkzeuge nach der Situation auswählen. Und das schließt Systemsprachen mit ein. Eine große, komplexe Unternehmensanwendung würde ich auch nicht mit einer Systemsprache schreiben, wenn auch nicht aus den hier immer so viel genannten "Systemfehlern", sondern wegen dem Schreibaufwand und der Tatsache das es in Sprachen wie z.B. Java und C# sehr viele Bibliotheken und Hilfsmittel gibt die, die Entwicklungszeit im Vergleich der Systemsprachen reduzieren.

l'abra d'or Mitglied 11:14:49 09.09.2010 Titel:

@asc:

Zitat:

11:11:11

Du hast doch sicher extra gewartet mit dem Abschicken, oder?

Unregistrierter

asc schrieb:

Eine große, komplexe Unternehmensanwendung würde ich auch nicht mit einer Systemsprache schreiben..

asc Mitglied 11:35:12 09.09.2010 Titel:

l'abra d'or schrieb:

@asc:

Zitat:

11:11:11

Du hast doch sicher extra gewartet mit dem Abschicken, oder?

Nein, aber irgendwie liegen mir solche Zeiten

l'abra d'or Mitglied 11:53:53 09.09.2010 Titel:

seldon schrieb:

Zunächst mal möchte ich diese Statistiken sehen, und ich möchte sehen wie und auf welcher Datenbasis sie erhoben werden. Einen Mechanismus, Codezeilen zu identifizieren, die Fehler verursachen, fände ich außerordentlich praktisch.

Ich finde es auch lustig einer automatisierten Lösung (sprich: Software) zu vertrauen, die herausfindet, dass 5% aller Codezeilen verbuggt sind