C++ Builder lastige Frage / ReallocMem und ReallocMemory

[TurboMagic]

Hallo,

ich bin immer noch dabei meine ToDO-Liste für die DEC
(https://github.com/winkelsdorf/Delph...tionCompendium)
abzuarbeiten. Ein Punkt dreht sich dabei um die Done Methode der Hash Basisklasse.
Diese wird praktisch bei jedem Hash-Vorgang am Ende aufgerufen. Und da drin liegt mein Verständnisproblem.
Siehe auch den Kommentar in der Methode.

Fragen:

1. Wozu braucht man ReallocMem hier, wenn doch FBuffer ein PByteArray ist und somit ein Zeiger auf ein
Array fixer größe? Der Code war schon in DEC 5.2 drin, nur wozu?

2. Welcher Unterschied ist zwischen ReallocMem(FBuffer, 0); und FBuffer := ReallocMemory(FBuffer, 0);?
Wenn ich mit wenig Aufwand auch C++ Builder kompatibilität umsetzen kann, warum nicht.
Nur muss es während der Entwicklung irgend ein Problem gegeben haben das dazu führte,
dass ich bei ReallocMem blieb. Anhand der vorhandenen Unit Tests kann ich das Problem
derzeit (in 10.3.3, die Entwicklung hatte ich aber in 10.1 übernommen/gestartet) nicht mehr
nachvollziehen. Weiß jemand ob sich da in diesen Routinen was getan hat?
Und wenn's C++ Builder kompatibel sein soll, muss es ReallocMem sein?

Delphi-Quellcode:

procedure TDECHash.Done;
begin
  DoDone;
  ProtectBuffer(FBuffer^, FBufferSize);

  FBufferSize := 0;
  // ReallocMemory instead of ReallocMem due to C++ compatibility as per 10.1 help
// Commented out, as it seems to not properly work with a new size of 0, but
// calling FreeMem is not correct either as it frees the pointer. One would get
// around of all of this by getting rid of PByte as buffer type completely by
// making it a TBytes variable
//  FBuffer := ReallocMemory(FBuffer, 0);

  ReallocMem(FBuffer, 0);
end;

[himitsu]

Länge 0 klingt eher danach, als wenn es hier ein FreeMem sein soll. :gruebel:


Bei ReallocMem wird es als VAR-Parameter reingegeben, während ReallocMemory den neuen Wert als Result zurück gibt.
Siehe auch GetMem und GetMemory.

Ich würde bei Länge 0 es als

Delphi-Quellcode:

FreeMem(FBuffer);
FBuffer := nil;

vermuten, ähnlich eimem FreeAndNil.

Warum hier FreeMem falsch sein soll, hab ich in dem Kommentar nicht verstanden.

Wobei ich auch lieber TBytes bzw. TArray<Byte> und deren automatische Speicherverwaltung verwende, anstatt mit GetMem und Co. rumzuhantieren.
So spare ich mir explizite Ressourcenschutzblöche (Try-Finally) und es kann auch nicht die Freigabe vergessen werden, da sie automatisch passiert. (die bis 16 Byte mehr für das dynamische Array fallen meistens nicht auf)

[TurboMagic]

Das mit TBytes verstehe ich ja, nur ist mir eine komplette Umstellung der Bibliothek zu
diesem Zeitpunkt zuviel. Das entsteht ja nicht auf der grünen WIese neu, sondern ist die
Weiterentwicklung aus 5.2 nur eben jetzt auch Crossplattform fähig.

[himitsu]

Mich würde aber mal interessieren, warum ReallocMem. und was an FreeMem sooooo schlimm sein soll, den im Prinzip sollte ReallocMem bei Length=0 intern zu FreeMem weiterleiten.

Zitat:

nur ist mir eine komplette Umstellung der Bibliothek zu diesem Zeitpunkt zuviel

Jo, versteh ich.

Ich wollte schon vor Ewigkeiten einen Teil übernehmen und in eine moderne neue API überführen.
Verschlüsselung, Komprimierung, Konvertierung mit einer einheitelichen Schnittstelle und über ein PÜluginsystem, wo man auch andere Verschlüsselungen/Komprimierungen/Konvertierungen nachrüsten kann.
Verknubbelt mit Generics und ClassOperatoren, aber hatte mich noch auf keine entgültige API-Struktur einigen können.

z.B. eine Variante wo man StringList/INI-ähnlich (Name/Modus + Parameter als "ein" String, ähnlich dem Format bei COM-Ports oder dem ConnectString bei Datenbanken) und einen Buffer/Array/Stream rein gibt und es als Buffer/Array/Stream raus gibt.
Auch mehrere Dinge nacheinander, in einer Funktion. (z.B. Verschlüsselung, Komprimierung und Base64 hintendran)

[TurboMagic]

Hast du schon mal die Doku von der in Arbeit befindlichen V6.0 angeschaut?
Ich habe das Ganze etwas weiter modularisiert.

Der nächste Schritt nach V6.0 wäre die Aufnahme weiterer v.a. modernerer Alrogithmen.
Mitstreiter gerne willkommen.

[TurboMagic]

Hallo,

ich habe mir das jetzt nochmal angeschaut und wie folgt umgesetzt:

Delphi-Quellcode:

procedure TDECHash.Done;
begin
  DoDone;
  ProtectBuffer(FBuffer^, FBufferSize);

  FBufferSize := 0;
  // ReallocMemory instead of ReallocMem due to C++ compatibility as per 10.1 help
  // It is necessary to reallocate the buffer as FreeMem in destructor wouldn't
  // accept a nil pointer on some platforms.
  FBuffer := ReallocMemory(FBuffer, 0);
end;

Damit sollte jetzt klar sein, warum der Code so ist, wie er ist.
Und du bist gerne eingeladen am Projekt mitzuarbeiten. Hast du schon die Doku
zur 6.0 gelesen? Da steht nämlich drin, was sich so alles seit eder 5.2 getan hat.
Das ist denke ich doch schon eine ganze Menge!

Na, hab' ich jetzt die Lust mitzuentwickeln geweckt?

[TurboMagic]

Jetzt hätt' ich doch noch eine Frage: hat jemand eine Ahnung wozu genau CalcMAC in TDECCipher in DECCipherBase.pas
gut sein soll? Ich kenne MAC halt als Message Authenticating Code und da müsste es ja ein irgendwie geartetes Secret
geben, welches mit einfließt aber nicht über die Leitung geht. ABer dafür gibt's ja keinen Parameter...

[TiGü]

Zitat:

Zitat von TurboMagic (Beitrag 1473341)

Jetzt hätt' ich doch noch eine Frage: hat jemand eine Ahnung wozu genau CalcMAC in TDECCipher in DECCipherBase.pas
gut sein soll? Ich kenne MAC halt als Message Authenticating Code und da müsste es ja ein irgendwie geartetes Secret
geben, welches mit einfließt aber nicht über die Leitung geht. ABer dafür gibt's ja keinen Parameter...

Alte Regel: Neue Frage -> neuer Thread!