C: Fragen zu memset, memcpy, malloc

[Peter(TOO)]

Hallo HaWe,

für den Fall, dass ich meinen dynamischen buf initialisieren will mit 128 statt mit 0, dann wäre doch vermutlich dieser Befehl dann auch richtig...

memset( buf, 128, arrlen*sizeof(int16_t) );

Richtig!

wie schon geschrieben wurde:
sizeof(Datentyp)
Gibt immer die Grösse in Bytes zurück. Dazu muss aber zur Compiltime die Grösse bekannt sein.
malloc(), memset(), mem...()
arbeiten ALLE mit der Byte-Anzahl, die haben keine Ahnung von Datentypen und deren Grösse.

calloc() macht die Multiplikation "sizeof() * n" selbst und ruft memset() mit 0 auf.

Grundsätzlich ist es egal ob du mit statischen Variablen oder welchen auf dem Heap arbeitest. Zeiger ist Zeiger, aber er muss auf einen gültigen Bereich zeigen!
Bei Variablen auf dem Heap bist du aber selbst verantwortlich, dass du nicht über den Rand der Variablen zugreifst, da kann dir der Compiler nicht helfen.

Daher kann man den Heap auch leicht zerschiessen.
Der Heap besteht meistens aus einer verketteten Liste. Die Informationen für die Verkettung liegt auf den Adressen vor dem Speicher, welcher dir malloc() liefert. Schreibst du hinter den dir zugesicherten Bereich, überschreibst du die Infos für die verkettete Liste des nächsten Blocks, dann kommt die Heap-Verwaltung durcheinander mit den lustigsten Effekten

Unsauber an deinem Code ist noch, dass man den Rückgabewert von malloc() überprüfen sollte!
Wenn kein Platz auf den Heap ist, liefert malloc() NULL als Rückgabewert!

ptr = malloc(size);
if (ptr )
  {
     // du kannst mit ptr arbeiten
  }
else
  {
    // Fehler: kein Platz auf dem Heap
  }

zudem habe ich mir auch angewöhnt:

  free(ptr);
  ptr = NULL;

Meist macht zumindest die Debug-Version einen Test auf NULL-Pointer, somit bekommst du beim Debuggen eine Fehlermeldung.
Je nach CPU und deren Speicherverwaltung, löst ein Schreibzugriff mit einem NULL-Pointer einen Exception-Interrupt aus.

Wenn man einen NULL-Pointer mit free() ist garantiert, dass free() nichts macht.
Gibt man einen bereits zurückgegebenen Block nochmals mit free() zurück, oder man übergibt free() irgendeinen Wert, zerschiesst du meistens der Heap, auf alle Fälle sind das dann oft schwer zu findende Fehler
Zur Laufzeit ist die Anordnung auf den Heap mehr oder weniger zufällig, weshalb sich solche Fehler oft auch nicht richtig reproduzieren lassen.

Ein häufiger Fehler ist auch, dass vergessen wird den Block mit free() an den Heap zurück zu geben. Dann geht dir irgendwann der freie Speicher aus und malloc() liefert NULL.

MfG Peter(TOO)

[HaWe]

super Tipps, vor allem das mit dem malloc Rückgabewert und dem Nullpointer nach free()!
Werde ich genau so machen, vielen Dank !

edit:
für

buf = (int16_t *)malloc(arrlen * sizeof (int16_t) );

heißt das dann
if(buf!=NULL) {...}

bzw.

if(buf==NULL) {
Serial.print("\n\n malloc() error - not enough memory\nprogram halted\n\n");
return;
}

richtig?

[Peter(TOO)]

super Tipps, vor allem das mit dem malloc Rückgabewert und dem Nullpointer nach free()!

Hat sich bei mir die letzten 25 Jahre so bewährt.

buf = (int16_t *)malloc(arrlen * sizeof (int16_t) );

heißt das dann
if(buf!=NULL) {...}

bzw.

if(buf==NULL) {
Serial.print("\n\n malloc() error - not enough memory\nprogram halted\n\n");
return;
}

richtig?

Jo!

Da für C alles !=0 als TRUE definiert ist, kann man auch verkürzt
if (buf) {...}
schreiben.

MfG Peter(TOO)

[HaWe]

perfekt, danke!

[Sisor]

Tipp: Um den Code lesbarer zu machen, Makros verwenden:
[Geschmacksache]

#define int16_malloc(len) (int16_t*)malloc(len*sizeof(int16_t))
#define delete(ptr)  free(ptr);ptr=NULL

int main() {
  
  int16_t* buf = int16_malloc(24);  // 24 * int16 allokieren
  if(buf) {
    //...  was mit buf anstellen
    delete(buf);
  }
  ...
}

[Mxt]

Vorsicht bei dem Namen "delete" für ein Makro.

Da HaWe und andere hier meist einen C++ Compiler benutzen um darin C zu machen. Das klein geschriebene delete ist ein reserviertes Wort in C++. Daher gibt es die Konvention Makros möglichst immer GROSS zu schreiben.

malloc und free sind in C++ eigentlich nur zur Rückwärtskompatibilität mit C vorhanden. Wenn man free auf einem Zeiger ausführt, der auf mit new angeforderten Speicher zeigt, oder andersrum aus Versehen delete auf mit malloc angeforderten Speicher aufruft, dann kann das Programm ganz plötzlich zuende sein.

[Sisor]

Das ist wohl richtig. Für c++ würde ich Makros auch nicht empfehlen.
Hier mal ein Auszug aus dem Arduino-Kern. Implementation von new und delete [new.cpp]:

#include <stdlib.h>

void *operator new(size_t size) {
  return malloc(size);
}

void *operator new[](size_t size) {
  return malloc(size);
}

void operator delete(void * ptr) {
  free(ptr);
}

void operator delete[](void * ptr) {
  free(ptr);
}

[Mxt]

Das sind spezielle Überladungen, die kommen bei normalem Anfordern von Speicher nicht zum Einsatz. Es handelt sich um sowas hier:
https://en.wikipedia.org/wiki/Placement_syntax

Man kann in C++ ja sowas machen

    #include <new>        // Must #include this to use "placement new"
    #include "Fred.h"     // Declaration of class Fred
    void someCode()
    {
      char memory[sizeof(Fred)];     // Line #1
      void* place = memory;          // Line #2
      Fred* f = new(place) Fred();   // Line #3 (see "DANGER" below)
      // The pointers f and place will be equal
      // ...
    }

das ist eine andere Baustelle.


Im übrigen ist es meist so, dass new und delete auf malloc und free zurückgreifen, oder auf die Betriebssystemfunktionen die diesese beiden verwenden.

Aber new und delete rufen auch Konstruktor und Destruktor der angelegten Objekte auf. Ein malloc würde nur Speicher anfordern, das Objekt darin aber nicht initialisieren. Ein free auf etwas mit new angefordertem würde einem Objekt den Speicher klauen, läuft doch später noch der Destruktor knallt es, usw.

[Sisor]

Interessant, schaue ich mir demnächst mal genauer an...