Fehler in FAQ

[Langnese]

In der FAQ sind Fehler:

-------

die includes werden nicht richtig dargestellt, vielleicht sollte

man die quoten, zwei spitze Klammern werden in HTML als Tag angenommen.

-------

int n = 4711;

char buffer[50];

sprintf( buffer, "%d", n );

Das ist genau der Grund, warum so viel SChrott mit C gemacht wird,

wer hat das denn in die FAQ geschrieben?

Vielleicht benutzt man hier nicht sprintf (benutzt man eigentlich NIEMALS,

wenn man guten Code schreibt) sondern snprintf.

Ausserdem fehlt ein include, die string.h muss mit rein!

-------

[Klotzkopp]

Original geschrieben von Langnese

die includes werden nicht richtig dargestellt, vielleicht sollte

man die quoten, zwei spitze Klammern werden in HTML als Tag angenommen.

Habe ich korrigiert, danke für den Hinweis.

wer hat das denn in die FAQ geschrieben?

Ich.

Vielleicht benutzt man hier nicht sprintf (benutzt man eigentlich NIEMALS,

wenn man guten Code schreibt) sondern snprintf.

Solange ich eine Obergrenze ermitteln kann (und solange man mir keinen int zeigt, der Zahlen von mehr als 49 Stellen fasst, kann ich das hier), finde ich "NIEMALS" ein wenig hart. Wir reden hier immerhin nicht von gets.

Wie sehen das die anderen?

Ausserdem fehlt ein include, die string.h muss mit rein!

Wofür?

[Guybrush Threepwood]

Original geschrieben von Klotzkopp

Solange ich eine Obergrenze ermitteln kann (und solange man mir keinen int

zeigt, der Zahlen von mehr als 49 Stellen fasst, kann ich das hier), finde

ich "NIEMALS" ein wenig hart. Wir reden hier immerhin nicht von gets.

Wie sehen das die anderen?

Sehe ich genauso, da man ja die Obergrenze selbst abschätzen kann und

es sich ja nicht um einen String handelt den ein Benutzer eingibt, der damit

einen Fehler verursachen könnte.

[Langnese]

Wofür?

[Guybrush Threepwood]

Von mir aus können wir auch snprintf nehmen, das macht bei dem Code

keinen Unterschied.

Es ist keine Sicherheitslücke, weil nur ein Integer umgewandelt wird, der,

egal welchen Wert er auch hat, keinen Speicherüberlauf verursachen kann.

Die Sache mit dem falschen Formatstring ist genau das selbe als wenn man

bei snprintf die flasche maximale Länge angibt.

[Klotzkopp]

Original geschrieben von Langnese

Du musst nur einen falschen Formatstring reinschreiben, schon hast du ne Sicherheitslücke.

Eine Sicherheitslücke, die durch Ändern des Codes eintritt, gibt es wohl immer. Das kann ich auch haben, wenn ich snprintf benutze:

"Du musst nur den zweiten Parameter größer machen als die Größe deines Puffers, ..."

oder

"Du musst nur mehr Formatstringfelder angeben als zusätzliche Parameter, ..."

Das ist für mich kein Argument, und wenn es für dich eins sein sollte, dürfte snprintf auch nicht besser sein.

Ist das so viel Aufwand snprintf zu benutzen?

Ich möchte ein anderes Beispiel bringen:

Verwendest du grundsätzlich std::vector::at, auch an den Stellen im Code, an denen std::vector::operator[] mit Sicherheit ausreichen würde, weil keine Bereichsüberschreitung auftreten kann?

Vorschlag: Ich füge dem FAQ-Beispiel den Hinweis hinzu, dass man auf Pufferüberläufe achten muss, wenn man die Länge des fertigen Strings nicht mit Sicherheit abschätzen kann, und verweise auf snprintf.

Das die string.h fehlt sagt der C-Standard.

Entschuldige bitte meine Zweifel, aber kannst du mich auf ein Kapitel verweisen? Ich finde das gerade nicht.

[Langnese]

Original geschrieben von Guybrush Threepwood

Von mir aus können wir auch snprintf nehmen, das macht bei dem Code

keinen Unterschied.

Es ist keine Sicherheitslücke, weil nur ein Integer umgewandelt wird, der,

egal welchen Wert er auch hat, keinen Speicherüberlauf verursachen kann.

Die Sache mit dem falschen Formatstring ist genau das selbe als wenn man

bei snprintf die flasche maximale Länge angibt.

Wenn _du_ das sagst...

Verwendest du grundsätzlich std::vector::at, auch an den Stellen im Code, an denen std::vector::operator[] mit Sicherheit ausreichen würde, weil keine Bereichsüberschreitung auftreten kann?

Ich rede hier von C nicht von c++!

Gruß

[Klotzkopp]

Original geschrieben von Langnese

Ich rede hier von C nicht von c++!

Und? Ich denke, möglicherweise überflüssige Sicherheitsabfragen sind ein sprachübergreifendes Thema.

Schade, dass du nicht auf den übrigen Inhalt meines Beitrags eingehst.