Valgrind meldet: Use of uninitialised value
-
Ich würde meistens wohl den Vergleich nicht per memcmp machen - der Wert des Paddings ist ja für die logische Äquivalenz zweier Variablen eines Struct-Typs überhaupt nicht von Interesse.
Ansonsten ist dort, wo man sich von Verhalten, das Valgrind bemängelt, einen Vorteil verspricht, "valgrind --gen-suppressions" ein Freund.
-
Steffo schrieb:
Würdet ihr da ein memset machen oder den Fehler hinnehmen?
Mich würde das einfach bei der Fehlersuche stören, d. h. die richtigen Fehler von den nicht wirklichen Fehler zu unterscheiden. Ich würde daher eher zu einem memset tendieren, dann meldet valgrind auch keine Fehler mehr.Bei einem einfachen unkritischen Programm würde ich das wohl auch machen. Aber wenn ich eine hochkritische Systembibliothek schreibe, dann würde ich es ganz bewusst nicht tun. Denn schließlich würde diese Entscheidung Millionen von Computern mit Millionen verschiedener Anwendungsszenarien betreffen. Und dann ist ein gesparter Takt ein gesparter Takt auf Millionen von Rechnern, jeweils millionenfach, Tag für Tag. Da wäre mir herzlich egal, dass ein dummes Debugprogramm da einen false-positive hat.
-
das memcmp ist ja kein false positive. Wenn da uninitialisierte padding bytes verglichen werden ist das Programmverhalten auch falsch.
-
In diesem Fall ist zwar nicht sichergestellt, welchen Wert das Padding hat, aber es ist nach memcpy sichergestellt, dass es in f und g den gleichen Wert hat. Das Verhalten ist da wohldefiniert, auch wenn uninitialisierter Speicher benutzt wird.
-
stimmt, habe ich jetzt genau wie valgrind verrafft.
Aber ich sehe noch nicht, wo man jemals so ein memcmp benutzen möchte... wenn Teile der verglichenen Werte zuƒällig entstanden sind, kann man doch auch nicht gescheit vergleichen?
-
Werte entstehen aber nicht zufällig. Das sieht vielleicht für ein Anwendungsprogramm so aus, aber ein Systemcall im Startupcode kann sich da drauf verlassen, als erster auf frisch genullten Speicher zuzugreifen. Die Überreste dieser Aufrufe sind es, wegen derer selbst bei einem frisch gestarteten Programm nicht alle Variablen mit 0 starten.
Außerdem können da durchaus auch noch andere Fehler sein. Das Beispiel demonstriert doch schön, dass es false-positives geben kann und dass die Behebung ein kleines bisschen Performance kosten würde. Und valgrind-Sauberkeit gegen Performance wäre in diesem Fall ein schlechter Tausch. Man kann sicherlich noch mehr Beispiele finden (bin aber gerade zu müde). Oder mal im Quellcode gucken, die glibc, die hier die konkreten Fehler verursacht hat, ist schließlich nicht geheim.
-
SeppJ schrieb:
...
Denn schließlich würde diese Entscheidung Millionen von Computern mit Millionen verschiedener Anwendungsszenarien betreffen. Und dann ist ein gesparter Takt ein gesparter Takt auf Millionen von Rechnern, jeweils millionenfach, Tag für Tag. Da wäre mir herzlich egal, dass ein dummes Debugprogramm da einen false-positive hat.Wie stehst du eigentlich zu Mikrokernel, Sicherheitssoftware, OpenBSD etc.?
-
Steffo schrieb:
SeppJ schrieb:
...
Denn schließlich würde diese Entscheidung Millionen von Computern mit Millionen verschiedener Anwendungsszenarien betreffen. Und dann ist ein gesparter Takt ein gesparter Takt auf Millionen von Rechnern, jeweils millionenfach, Tag für Tag. Da wäre mir herzlich egal, dass ein dummes Debugprogramm da einen false-positive hat.Wie stehst du eigentlich zu Mikrokernel, Sicherheitssoftware, OpenBSD etc.?
Ich meine, wenn du denkst, dass meine Meinung hierzu relevant wäre, dann hast du meine Erklärung (absichtlich?) nicht verstanden.
-
Ich kann mir nur schwer vorstellen, dass Software, die extrem auf Sicherheit optimiert sind, auch nur eine Warnung zulässt. Soll jemand, der die libc verwendet, extra im Quellcode nachgucken, um zu schauen, wie sicherheitsrelevant der Fehler ist? Er würde eher zu einer Alternative wechseln (vielleicht libc von OpenBSD?).
-
Ich kann mir nur schwer vorstellen
Ich sag mal so: Deswegen lässt man dich keine Entscheidungen treffen.
Der Thread ist ins extreme Offtopic abgedriftet. Wenn du deine geringe Vorstellungskraft oder Unverständnis der Sachlage weiterhin öffentlich kundtun möchtest, dann kannst du einen passenden Diskussionsthread dazu in TrudPC aufmachen.
