Wofür C++ und C?
-
Mr. N schrieb:
In C++ ist ein Buffer Overflow nur einfach, wenn man es falsch benutzt. In C produzieren den selbst Profis am laufenden Band.
-------------------------- /| /| | | ||__|| | Trolle bitte | / O O\__ nicht | / \ füttern! | / \ \ | / _ \ \ ---------------------- / |\____\ \ || / | | | |\____/ || / \|_|_|/ | __|| / / \ |____| || / | | /| | --| | | |// |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // | / * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____________
-
Undertaker schrieb:
Mr. N schrieb:
In C++ ist ein Buffer Overflow nur einfach, wenn man es falsch benutzt. In C produzieren den selbst Profis am laufenden Band.
<<Snip>>Sorry, das war ernst gemeint. Ich lese ständig Sicherheitswarnungen über Buffer-Overflows in C-Programmen...
Und wenn ich bedenke, dass strcat, sprintf etc. Buffer-Overflows geradezu erzwingen und so Funktionen wie strncat auch nicht viel besser sind, dann lob ich mir doch mein std::string. :p
-
wenn man bedenkt, dass C ein Teil von C++ ist.
-
Mr. N schrieb:
Und wenn ich bedenke, dass strcat, sprintf etc. Buffer-Overflows geradezu erzwingen und so Funktionen wie strncat auch nicht viel besser sind, dann lob ich mir doch mein std::string.
hast du nicht gesagt, dass buffer-overflows passieren können, wenn man irgendwas falsch benutzt? selbiges gilt auch für std::string, z.b. einen char* geholt mit c_str() oder data() und die overflow-gefahren sind alle wieder da. auch wenn du alles richtig machst, besteht immer noch die möglichkeit, dass std::string seine capacity nicht erhöhen kann (weil der globale heap zu 99% voll ist). es gibt keine sicherheit in C und C++. C++ bietet vielleicht eine trügerische sicherheit, aber ich bezweifle dass das irgendwie besser ist als gar keine sicherheit (wie in C). eher schlimmer.
-
Beides falsch (gemäß dem Titel werde ich die Aussagen nicht wiederholen).
Gruß,
Simon2.
-
gibts auch was bei C++ das man nicht falsch machen kann?
-
... und warum bin ich ein Unreg-Troll, der keine Freunde aber haufenweise Pickel hat ?
-
frage. schrieb:
gibts auch was bei C++ das man nicht falsch machen kann?
ich glaube nicht.
könnte schon sein, dass C++ von allen programmiersprachen die sprache ist, mit der man theoretisch pro codezeile die meisten fehler produzieren kann.
-
Könnte aber viel eher ein, dass Undertaker der Troll ist, der den meisten Unsinn pro Zeile verfasst.
-
Undertaker schrieb:
Mr. N schrieb:
Und wenn ich bedenke, dass strcat, sprintf etc. Buffer-Overflows geradezu erzwingen und so Funktionen wie strncat auch nicht viel besser sind, dann lob ich mir doch mein std::string.
hast du nicht gesagt, dass buffer-overflows passieren können, wenn man irgendwas falsch benutzt? selbiges gilt auch für std::string, z.b. einen char* geholt mit c_str() oder data() und die overflow-gefahren sind alle wieder da.
Falsch, c_str() und data() liefern konstante C-Strings (char const *).
Undertaker schrieb:
auch wenn du alles richtig machst, besteht immer noch die möglichkeit, dass std::string seine capacity nicht erhöhen kann (weil der globale heap zu 99% voll ist).
Aber das konstituiert keine Sicherheitslücke.
[Außer vielleicht ein DoS, aber dagegen ist man nie ganz geweiht.]Undertaker schrieb:
es gibt keine sicherheit in C und C++. C++ bietet vielleicht eine trügerische sicherheit, aber ich bezweifle dass das irgendwie besser ist als gar keine sicherheit (wie in C). eher schlimmer.
So ein Blödsinn. std::string halbwegs(*) richtig benutzen ist leicht. Und subtile Gefahren gibt es da auch nicht wirklich.
(*): So Dinge wie void foo(std::string x); sind zwar nicht wirklich richtig, aber kein wirkliches Problem, außer für die Performance.
-
So Dinge wie void foo(std::string x); sind zwar nicht wirklich richtig, aber kein wirkliches Problem, außer für die Performance.
man, kann man da viel falsch machen.
-
Undertaker schrieb:
könnte schon sein, dass C++ von allen programmiersprachen die sprache ist, mit der man theoretisch pro codezeile die meisten fehler produzieren kann.
Das kann so sein, muss aber nicht : http://www.c-plusplus.net/forum/viewtopic-var-t-is-192168.html
-
Mr. N schrieb:
std::string halbwegs(*) richtig benutzen ist leicht. Und subtile Gefahren gibt es da auch nicht wirklich.
denk doch nur mal an operator[]
-
Undertaker schrieb:
Mr. N schrieb:
std::string halbwegs(*) richtig benutzen ist leicht. Und subtile Gefahren gibt es da auch nicht wirklich.
denk doch nur mal an operator[]
Was soll damit sein? Der kann auch secure sein, siehe MSVC8.0 (da sind alle []-Operatoren der C++-Standard-Library secure als Compiler-Default-Setting!).
Was willst du uns eigentlich beweisen? Deine C++ Inkompetenz? Nicht nur die []-Frage sondern auch die c_str()-Frage beweist das, innerhalb zwei Postings hintereinander.... Go Home Kid! *PLONK*
-
Fred closed oder 20+ Seiten.
-
Artchi schrieb:
Was willst du uns eigentlich beweisen? Deine C++ Inkompetenz?
Er hat doch nie etwas gegenteiliges behauptet.
-
Ja, halt ein Troll, der so krank ist, das er es nicht mal einsieht. Und wenn er es weiß, scheint er absichtlich ein Troll zu sein und somit ein Arsch**** durch und durch.
-
Wer kann's ihm verdenken, er wird ja gut gefüttert hier. Am meisten von denen, die lange dabei sind und es eigentlich wissen müssten.
-
Artchi schrieb:
Undertaker schrieb:
Mr. N schrieb:
std::string halbwegs(*) richtig benutzen ist leicht. Und subtile Gefahren gibt es da auch nicht wirklich.
denk doch nur mal an operator[]
Was soll damit sein? Der kann auch secure sein, siehe MSVC8.0 (da sind alle []-Operatoren der C++-Standard-Library secure als Compiler-Default-Setting!).
lobenswerte sache von m$. ich dachte immer, da sind aus geschwindigkeitsgründen keine checks drin. noch meine vs2003-codes haben sich bei astronomischen indexwerten immer verabschiedet. bereichsüberprüfungen von [] sind aber nicht standard, nehme ich an.
Bashar schrieb:
er wird ja gut gefüttert hier.
hmmmm, mampf, schmatz, lecker
-
Und wie baut man mit operator[] eine Sicherheitslücke?