Wofür C++ und C?
-
Tim schrieb:
...
"Da es std::string in C nicht gibt, muss man sich in C halt überlegen wie man es, den Anforderungen entsprechend, effizient löst." z.B.Kann ich gut mit leben.
Für mich ist das halt "der kanonische Weg in C" und alles Andere eher exotisch - weswegen ich schrieb "geht nicht anders" (meinte: "Geht nicht mit std::string" oder gar "geht nicht besser" ... wobei ich natürlich weiß, dass "besser "relativ ist). Außerdem war das von mir nur eine Randbemerkung und es ging mir nie wirklich um C (hatte gedacht, dass das aus dem Kontext heraus ersichtlich gewesen sei).Aber gut, dass Du mit einer eindeutigeren und exakteren Formulierung hier Klarheit geschaffen hast.
Gruß,
Simon2.
-
Mr. N schrieb:
Sagt dir Buffer Overflow und One Off Error etwas?
Sind doch so typische C/C++ Fehler.
-
scnr schrieb:
Mr. N schrieb:
Sagt dir Buffer Overflow und One Off Error etwas?
Sind doch so typische C/C++/Java/Smalltalk/Cobol/Fortran/ASM/... (choose one) Fehler.
Der ist einfach so schön, der muss wieder her:
-------------------------- /| /| | | ||__|| | Trolle bitte | / O O\__ nicht | / \ füttern! | / \ \ | / _ \ \ ---------------------- / |\____\ \ || / | | | |\____/ || / \|_|_|/ | __|| / / \ |____| || / | | /| | --| | | |// |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // | / * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c____________Gruß,
Simon2.
-
Um mit Java nen Buffer Overflow hin zu bekommen, musst du dich schon richtig gut auskennen, und wer sich so gut auskennt macht solche Fehler nicht. Aber in C++ bekommt die jeder Anfänger hin und macht sie auch.
Simon2 schrieb:
Ich bin dumm
ich kann dich auch falsch zitieren
-
scnr schrieb:
Simon2 schrieb:
Ich bin dumm
ich kann dich auch falsch zitieren
Auch wenn er Dich richtig zitiert hätte, wär's nicht besser gewesen. Man könnte der Liste noch VB6 hinzufügen, selbst da kann man mit etwas Know-How einen Buffer Overflow hinbekommen.
-
scnr schrieb:
Um mit Java nen Buffer Overflow hin zu bekommen, ...
"Lesen, mein lieber Watson !! Lesen ist das A und O beim Verstehen !"
-
na dann is ja gut
-
In C++ ist ein Buffer Overflow nur einfach, wenn man es falsch benutzt. In C produzieren den selbst Profis am laufenden Band.
-
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