Werden frische Speicherseiten genullt?
-
So sieht's aus schrieb:
Wenn man das Programm frisch startet und Speicher einmalig anfordert, dann dürfte man wohl nur frische Seiten bekommen
Du bekommst immer entweder frische Seiten oder deine eigenen.
Ergo: was genau willst du auslesen? Deine eigenen Daten? Ja, das könnte natürlich sein dass du diese wieder zurück bekommst. Aber fremde Daten nicht.
-
Shade Of Mine schrieb:
So sieht's aus schrieb:
Wenn man das Programm frisch startet und Speicher einmalig anfordert, dann dürfte man wohl nur frische Seiten bekommen
Du bekommst immer entweder frische Seiten oder deine eigenen.
Ergo: was genau willst du auslesen? Deine eigenen Daten? Ja, das könnte natürlich sein dass du diese wieder zurück bekommst. Aber fremde Daten nicht.
ist das iwo definiert oder hast dir das gerade ausgedacht?
-
@Shade:
Source pls.Weil hier scheint nur jemand eine Ahnung zu haben und keine Quellen nachweisen zu können.
Dravere ist ein Vorzeigebeispiel, was Quellen anbelangt.
-
Dravere schrieb:
Es war mal in POSIX drin, wurde aber inzwischen rausgenommen:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html#tag_13_80Ah, danke. War zu bequem, das selbst nachzuschlagen.
Jedenfalls ist es nicht Linux-spezifisch, wie von "So sieht's aus" vermutet. Auch wenn es nicht mehr Posix-standardisiert ist, werden das vmtl. alle Unices in den nächsten Jahrzehnten unterstützen (müssen).
-
Shade Of Mine schrieb:
Du bekommst immer entweder frische Seiten oder deine eigenen.
Das ist eine Vermutung (im ursprünglichen Thread ging es nicht um irgend ein konkretes OS) und keine Garantie. Selbst die SUS garantiert dies nicht.
-
Dravere schrieb:
@nman,
Es war mal in POSIX drin, wurde aber inzwischen rausgenommen:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html#tag_13_80
(ziemlich weit unten unter Issue 6, am besten die Dokumentsuche des Browsers nehmen)Ein Blick in die SUSV2 zeigt, daß sbrk den Speicher nullen muß, falls er einem Prozeß neu zugeteilt wird, aber das ist nur noch historisch. Zudem ist nicht garantiert, daß Speicher vom Kernel durch sbrk zur Verfügung gestellt wird.
In SUSV2, SUSV3 und SUSV4 wird jedenfalls nicht garantiert, daß der Speicher bei malloc Anforderungen genullt wird. Das OS kann dies tun, aber es kann es auch einfach sein lassen, und wäre damit immer noch konform.
-
Linux, BSD und Windows nullen.
Siehe Dokumentation zu sbrk und VirtualAlloc.Sourcen wurden also schon genannt. Natürlich muss es bei einem anderen System nicht so sein...
-
Shade Of Mine schrieb:
Linux, BSD und Windows nullen.
Siehe Dokumentation zu sbrk und VirtualAlloc.Sourcen wurden also schon genannt. Natürlich muss es bei einem anderen System nicht so sein...
Auch wenn ich mit malloc den Speicher anfordere?
-
frage herr lehrer schrieb:
Shade Of Mine schrieb:
Linux, BSD und Windows nullen.
Siehe Dokumentation zu sbrk und VirtualAlloc.Sourcen wurden also schon genannt. Natürlich muss es bei einem anderen System nicht so sein...
Auch wenn ich mit malloc den Speicher anfordere?
Christoph schrieb:
malloc() würde auch nichts helfen, denn dabei laufen die Speicherseiten auch schon durch die C-Runtime. Statt frische Seiten vom OS zu bekommen, kannst du bei malloc() auch alte Seiten bekommen, die dein Programm früher mal benutzt hat.
-
frage herr lehrer schrieb:
Auch wenn ich mit malloc den Speicher anfordere?
Was macht denn malloc? Da steckt ja keine Magie oder so dahinter. malloc kann auch nur irgendwann die Kernel Funktionen aufrufen. zB ruft malloc alloc auf, alloc ruft xallac auf und xalloc ruft foolloc auf und foolloc ruft VirtualAlloc auf. Natürlich kann dann in den Seiten was drinnen stehen - sie sind ja durch viele Hände gegangen. Aber irgendwann wurde diese Seite von VirtualAlloc bereitgestellt und dort wurde sie genullt. dh alles was an Datenschrott da drinnen steht, hat malloc, alloc, xalloc oder foolloc dort reingeschrieben. zB weil eben aus Performance Gründen die Seiten in Blöcken allokiert werden.