Frage zu realloc()

Reallokierer schrieb:
> Wie funktioniert eigentlich realloc()?
> Sucht das Betriebssystem(?) quasi bei einer Anfrage nach (zB.)
> Vergrößerung des Speichers einen neuen zusammenhängenden
> Speicherbereich? D.h, ich bekäme nach jedem:
> addr = realloc(str, strlen(buffer)+new_len+1);
> eine neue Adresse?
Ja, darauf das sich addr bei jedem realloc() ändert muss Deine Software 
vorbereitet sein. Aber immer passiert das nicht.

Reallokierer schrieb:
> Und falls ja, was passiert dann mit dem alten Speicher? Dieser müsste ja
> dann automatisch freigegeben werden, oder?

Der wird von der Speicherverwaltung recycelt und steht dann wieder als 
freier Speicher für alloc() zur Verfügung.

Reallokierer schrieb:
> Sucht das Betriebssystem(?)

Nicht das Betriebssystem, sondern die Heapverwaltung der 
Laufzeitumgebung Deines Compilers.

holger schrieb:
> ... die dann für eine kräftige Fragmentierung sorgen können.

Nach der gar keiner gefragt hatte.  Ich kann diese ewige „malloc ist
per se böse“-Leier einfach nicht mehr erhören.

Zum TE: der Variantenreichtum der Implementierungen ist dabei extrem
groß.  Das ist auch eine Frage, ob du auf einem System mit virtuellem
Speicher arbeitest (bei dem man recht großzügig sein kann) oder es
eine eher kleine Umgebung mit chronischer Speicherknappheit ist.

holger schrieb:
> ... die dann für eine kräftige Fragmentierung sorgen können.

Dafür braucht es kein realloc, das geht mit malloc, calloc und 
free genausogut.

holger schrieb:
> Etwas Hintergrund kann aber nicht schaden.

Dann präzisiere das doch. Denn auf einem halbwegs modernen PC wirst du 
schon ziemlich viel tun müssen bis du da etwas merkst.

holger schrieb:
> auf diesem Weg macht es realloc

Aha, du weißt es ja genau.

Hast du denn selbst schon mal eins geschrieben oder dir angesehen,
wie eins funktioniert, welches andere geschrieben haben?

Man kann es sicher auf diesem Wege machen, aber das ist eher ein
Notnagel denn eine vernünftige Implementierung.

Reallokierer schrieb:
> Also quasi so ne Art "Middleware" zwischen OS und Anwendung.

Ja, nennt sich Standardbibliothek.  OS muss übrigens nicht sein.

kommt drauf an...

Man muß sich halt bewusst sein, welche Resourcen man hat, wieviel man 
braucht und was man sinnvollerweise macht, wenn es eng wird.

Wenn man den Überblick nicht hat (warum auch immer), dann besser die 
Finger davon lassen.

Das ist wie mit gutem (scharfem) Werkzeug. Wenn man nicht damit umgehen 
dann, dann lieber nicht anfassen.

Reallokierer schrieb:
> den Befehl verwenden?

Wenn du ein dynamisches Problem hast, wirst du mit einer statisch
vorallozierten Implementierung kaum besser kommen als mit malloc(),
denn du riskierst, dass deine Implementierung Bugs mit sich bringt,
die aus dem „offiziellen“ malloc() alle schon rausgeschüttelt sind.

Du solltest dir natürlich genau ansehen, auf welche Weise man das
mit der Newlib daherkommende (und durch deine selbst zu erstellende
_sbrk()-Backend-Funktion zu untersetzende) malloc() „auf die sichere
Seite“ bekommt, sprich, das Risiko einer Kollision von Heap und Stack
möglichst gering zu bekommen.

Eine Anwendung mit dynamischem Datenanfall muss immer für die
Situation gerüstet sein, dass sie mehr Daten bekommen könnte, als
sie Speicher zur Verfügung hat, und muss daraus einen Ausweg haben.
Das ist komplett unabhängig davon, ob man die Verwaltung einem
malloc() überlässt oder statisch vorbelegt (bei letzterem wird der
Fall sogar mit großer Wahrscheinlichkeit schon eher eintreten).

Wenn du ein rein statisch lösbares Problem hast, stellt sich die Frage
eigentlich gar nicht. ;-)

Bitflüsterer schrieb:
> 2. Falls dieses Array nicht per se wie ein Ringpuffer oder
> Kellerspeicher bedient wird, schreibt man sich eine eigene kleine
> Verwaltung für die Einträge (ein paar Zeiger oder/und ein Flag in einer
> Struktur die dann in dem Array gespeichert wird).

Dann bist du bei dem Punkt, den ich oben nannte: das Risiko, da Bugs
einzubringen, ist deutlich größer, als wenn man gleich malloc() nimmt.

Letztlich ist malloc() auf einem Controller auch weiter nichts als
die Verwaltung eines großen Byte-Arrays, welches sich zwischen dem
Ende der statischen Daten und dem Stack befindet.  Beim malloc() aus
der (hier relevanten) Newlib kann man es sogar vollständig so nutzen,
da man dort die Backend-Funktion _sbrk() ohnehin selbst liefern muss,
die den nächsten freien Speicherblock anfordert.

Aber auch beim statischen Array als „Heap“ hat man das Risiko, wenn
man dieses zu groß macht, dass da der Stack hineinrennt …  Nur, dass
da eben kein malloc() mehr eine 0 zurückgeben kann.

Otto Realverbraucher schrieb:
> Wenn es garantiert ist, dass in der Zukunft die Größe/Länge des
> allokierten Speichers gleich bleibt oder kleiner wird,
> 1. bleibt die Anfangs-Adresse gleich? (ISO, C99 od. Sonstiges?)
> 2. werden die nicht mehr benötigten Bytes ("Delta") am Ende freigegeben?

Nichts davon ist garantiert.

Was die avr-libc-Implementierung betrifft, handhabt sie das im Prinzip
so, aber den Sourcecode kannst du dir ja selbst ansehen.

Ich denke nicht, dass solche Verrenkungen irgendwelcher Art wirklich
was bringen.

Entweder hast du ein Problem, welches sich mit statisch belegtem
Speicher erledigen lässt, d. h. alle Details sind zur Compilezeit
bekannt.  Dann brauchst du kein malloc().  Oder du hast wirklich
dynamische Daten, weißt zur Compilezeit also nicht, was wirklich wann
auf dich zukommt.  Dann brauchst du 1.) immer (egal ob malloc()
oder nicht) eine „Exit-Strategie“, also irgendeine Maßnahme, die du
dann ergreifen kannst, wenn die Datenflut größer wird, als deine
Speichermöglichkeiten es hergeben.  2.) brauchst du dann einen
Allokator, bspw. eben malloc().

Bei wirklich zufälligen Anforderungen an die Größe der jeweiligen
Speicherblöcke ist die Gefahr von Fragmentierung nicht so groß, wie
das gemeinhin angenommen wird.  Sofern überhaupt noch ein paar
Reserven da sind, gleicht sich das über die Programmlaufzeit wieder
aus.

Deine Variablen „ptr“, „b“, „c“ und „i“ spielen dabei nur insofern
eine Rolle, als dass sie beim Eintritt in die Funktion Stack belegen
könnten (oft genug wird sie der Compiler ohnehin in Registern
halten).  Der für den Stack benutzte Platz steht dem Heap nicht mehr
zur Verfügung, der ist also schon weg, bevor dein malloc() da
überhaupt aufgerufen wird.