UnpackMemory - Zielspeichergröße

[STARGÅTE]

Tachchen,

Triviale Frage:

Wenn ich eine gepackten Speicherbereich entpacke, die entpackte Größe aber nicht (nicht mehr) kenne, habe ich keine Chance diese herauszufinden oder ? Also bevor ich UnpackMemory anwende ...

Oder steht die im Header des gepackten Bereichs drin ?

Denn wenn ich doch mal zu zuwenig bereit halte, schreibt ja UnpackMemory einfach drüber weg und macht große Probleme ...

Muss ich also beim Anwenden von PackMemory() immer selber noch die Ursprungsgröße noch vorweg speichern?

[GPI]

Mir wäre nichts bekannt. Wäre übrigens keine Schlechte idee in PB das zu erweitern. Einfach einen zusätzlichen Header einfügen und PB sollte beim entpacken kontrollieren ob der Header da ist oder nicht und entsprechen reagieren.

[Batze]

Ist ja zum Glück nicht so schwer da mal eben ein int mit der Größe davor zu schreiben. Einbauen wäre natürlich auch nett.

[GPI]

Tip: Häng nicht nur ein long für die Größe davor. Mach ein "Header"

bspw.

Code: Alles auswählen

data.l 'MyPC'
data.l <länge>
data <gepackte daten>

das MyPC als kennung davor. Solltest du nämlich, aus welchen Gründen auch immer, mal erweitern müssen, kannst du einfach diesen Magiccode ändern und weitere Datenfelder einfügen. Es ist also leichter erweiterbar. (Wenn dir bspw. später einfällt, das es sinnvoll gewesen wäre, ein CRC-Prüfsumme einzufügen. Mit der Kennung kannst du dann sowohl die alten Daten als auch die neuen Daten laden).

[Batze]

Tip: Häng nicht nur ein long für die Größe davor. Mach ein "Header"

bspw.

Code: Alles auswählen

data.l 'MyPC'
data.l <länge>
data <gepackte daten>

das MyPC als kennung davor. Solltest du nämlich, aus welchen Gründen auch immer, mal erweitern müssen, kannst du einfach diesen Magiccode ändern und weitere Datenfelder einfügen. Es ist also leichter erweiterbar. (Wenn dir bspw. später einfällt, das es sinnvoll gewesen wäre, ein CRC-Prüfsumme einzufügen. Mit der Kennung kannst du dann sowohl die alten Daten als auch die neuen Daten laden).

Würde sogar dazu tendieren noch sowas wie eine versionsnummer zu verwenden, sonst ist der schöne Magiccode verbraucht und man muss was anderes nutzten, obwohl vielleicht nur ein wenig dazugekommen ist.

[HeX0R]

Soviel ich weiß steht die Ursprungsgröße bei

Code: Alles auswählen

PeekL(*PackedMemory + 2)

[GPI]

Soviel ich weiß steht die Ursprungsgröße bei

Code: Alles auswählen

PeekL(*PackedMemory + 2)

oh, mit sowas wär ich vorsichtig, da undokumentiert... Wäre nett, wenn das in die Dokumentation einfließen würde. Am besten als UnPackedLength()-Funktion.

[Thorium]

Soviel ich weiß steht die Ursprungsgröße bei

Code: Alles auswählen

PeekL(*PackedMemory + 2)

oh, mit sowas wär ich vorsichtig, da undokumentiert... Wäre nett, wenn das in die Dokumentation einfließen würde. Am besten als UnPackedLength()-Funktion.

Das ist auch falsch, da es nur für JCalG1 gild, welcher nur unter x86 verwendet wird. Unter x64 ist die Magic vom Header 3 Byte lang.
Dokumentiert ist es aber natürlich: http://www.bitsum.com/jcalg1.htm

[GPI]

Das ist zwar dokumentiert, aber nicht für PureBasic. Großer Unterschied.

[Thorium]

Das ist zwar dokumentiert, aber nicht für PureBasic. Großer Unterschied.

Wieso? PB nutzt die JCalG1 Lib für x86.