[FAQ] Dynamischer Speicher mit malloc/calloc/realloc/free

Tim schrieb:

O.K. aber das würde imho zu weit führen.

stimmt, dein text behandelt ja speziell malloc/realloc/free usw.
na gut, was mir noch einfällt:
- was passiert wenn man malloc(0), free(0) usw. aufruft?
- wie reagieren wenn malloc 0 zurückgibt?
- probleme mit malloc/realloc und IPC, shared libraries, dlls (verschiedene heaps!)?
- werdem memory leaks hinterlassen, wenn ein programm abschmiert.
- vorteile/nachteil von malloc/free/realloc in systemen mit wenig speicher.
- wo bekommen malloc/realloc den speicher her?

heap-fan schrieb:

Tim schrieb:

O.K. aber das würde imho zu weit führen.

stimmt, dein text behandelt ja speziell malloc/realloc/free usw.
na gut, was mir noch einfällt:
- was passiert wenn man malloc(0), free(0) usw. aufruft?
- wie reagieren wenn malloc 0 zurückgibt?
- probleme mit malloc/realloc und IPC, shared libraries, dlls (verschiedene heaps!)?
- werdem memory leaks hinterlassen, wenn ein programm abschmiert.
- vorteile/nachteil von malloc/free/realloc in systemen mit wenig speicher.
- wo bekommen malloc/realloc den speicher her?

gut, dann fang schonmal an

heap-fan schrieb:

Tim schrieb:

O.K. aber das würde imho zu weit führen.

stimmt, dein text behandelt ja speziell malloc/realloc/free usw.
na gut, was mir noch einfällt:
- was passiert wenn man malloc(0), free(0) usw. aufruft?
- wie reagieren wenn malloc 0 zurückgibt?
- probleme mit malloc/realloc und IPC, shared libraries, dlls (verschiedene heaps!)?
- werdem memory leaks hinterlassen, wenn ein programm abschmiert.
- vorteile/nachteil von malloc/free/realloc in systemen mit wenig speicher.
- wo bekommen malloc/realloc den speicher her?

Sorry, aber das ist mir schon zu speziell (Plattformspezifisch etc.) als dass ich das in einen FAQ-Eintrag hier in ANSI C behandeln würde. Das wären imho alles Themen für einen Artikel.

Und bez. "wie reagieren wenn malloc 0 zurückgibt?": Da gibts doch eh kein 100%-Gelingen-Rezept. Da gabs in "Rund um die Programmierung" erst letztens eine Diskussion, ob man dem Fall überhaupt noch die Chance hat was zu retten etc. Nein, das würde den Eintrag sprengen. Ich will hier kein "C von A bis F" schreiben.

jepp schrieb:

gut, dann fang schonmal an

okay, -->
X. malloc(0)
Ein Aufruf von malloc() mit 0 als Argument ist implementationsabhängig. Es sind zwei Resultate möglich.
1. malloc() gibt einen NULL Zeiger zurück.
2. malloc() gibt einen Zeiger ungleich NULL zurück. Obwohl kein benutzbarer Speicher alloziert wurde, existiert auf dem Heap ein Listeneintrag, der mit free() wieder gelöscht werden muß.

gut,
man könnte sich die frage stellen, welcher grund einen programmierer bewegen könnte 0 byte arbeitsspeicher anzufordern *grübel*

jepp schrieb:

man könnte sich die frage stellen, welcher grund einen programmierer bewegen könnte 0 byte arbeitsspeicher anzufordern *grübel*

das könnte z.b. bei berechneten mallocs passieren, etwa bei malloc (a * sizeof(b));, wenn b 0 ist.

Gut, aber das ist dann ein Bug den man fixt ohne wissen zu müssen wie malloc() in so einem Fall reagiert (was ja eh wieder "implementation defined" wäre).

edit: außerdem meinst du wohl eher "wenn a 0 ist"

Tim schrieb:

edit: außerdem meinst du wohl eher "wenn a 0 ist"

ja, das meinte ich.

rüdiger

Ich fände es gut, wenn du die richtige Verwendung von man: realloc(3) erklären könntest. Man sieht zu oft p = realloc(p, N) .

rüdiger schrieb:

Ich fände es gut, wenn du die richtige Verwendung von man: realloc(3) erklären könntest. Man sieht zu oft p = realloc(p, N) .

Das habe ich mir hier, etwas kryptisch vielleicht, notiert:

TODO: Mögliches Speicherleck bei falschem Aufruf von realloc()

rüdiger

btw. zum casten von malloc. Auf m68k kann das wohl böse enden, da Adressen und Integer dort unterschiedliche Register haben: http://www.grep.be/blog/en/computer/debian/m68k/broken_c_code

rüdiger schrieb:

btw. zum casten von malloc. Auf m68k kann das wohl böse enden, da Adressen und Integer dort unterschiedliche Register haben

das war wohl eher ein unfähiger compiler, der casts nicht richtig beherrscht.

rüdiger

nö, weil in dem Beispiel in der Datei mit der main-Funktion die Funktion als void *f(); deklariert wurde. Aber das ist auch total OT...

rüdiger schrieb:

nö, weil in dem Beispiel in der Datei mit der main-Funktion die Funktion als void *f(); deklariert wurde.

stimmt, du hast recht. falscher prototyp, das hab' ich übersehen.