Hallo,

jemand hat einen Bug in DEC (Delphi Encryption Compendium, https://github.com/MHumm/DelphiEncryptionCompendium)
gefunden, der darauf basiert, dass die vorhergehenden Entwickler an vielen Stellen PByte als Datentyp benutzt haben, was ja bekanntlich ein Zeiger auf einen 32K großen Byte
Block ist.

Verarbeitet man nun Daten die größer als 32K sind, gibt's einen RageCheckError. Soweit so klar.
Die Lösung kann auch nicht sein den Range Check auszuschalten, auch nicht selektiv an den Stellen.

Der Melder schlägt vor (Issue 47), einen
eigenen Arraytypen zu definieren:

TDECByteArray = array[0..MaxInt-1] of Byte; Man könnte darauf basierend ja einen Zeiger Typen irgendwie deklarieren, aber ich bin mir da noch recht im unklaren:

• Wie müsste sowas aussehen um Delphi und FPC kompatibel zu sein?
• Welche anderen probleme wirft eine Umstellung auf so einen Typen auf?
• Gibt es schon einen passenden vordefinierten Typen in Delphi und FPC? Ab welcher Delphi Version?

Grüße
TurboMagic

Zitat von TurboMagic:

PByte als Datentyp benutzt haben, was ja bekanntlich ein Zeiger auf einen 32K großen Byte
Block ist.

Hier steige ich schon aus.
PByte ist ein Zeiger auf ein Byte . Wo kommen jetzt die "32 K" her?

Update: Du meinst PByteArray bzw. TByteArray. Letzteres ist definiert als type TByteArray = array [0..32767] of Byte;

.. da gibt es doch auch noch TByteDynArray.
Welches in der Größe variable ist.

Gibt es auch in FPC

Grüße
Klaus

Zitat von Der schöne Günther:

Zitat von TurboMagic:

PByte als Datentyp benutzt haben, was ja bekanntlich ein Zeiger auf einen 32K großen Byte
Block ist.

Hier steige ich schon aus.
PByte ist ein Zeiger auf ein Byte . Wo kommen jetzt die "32 K" her?

Update: Du meinst PByteArray bzw. TByteArray. Letzteres ist definiert als type TByteArray = array [0..32767] of Byte;

Ja, ich meine natürlich PByteArray... Sorry!

Alternativ könntest Du auch mit Streams anstelle array of whatever arbeiten, theoretisch endloser speicher...

TByteDynArray oder PByte + Länge würden sich anbieten. Oder wie KodeZwerg schrieb: Ein Stream (TMemoryStream oder was auch immer). Letzteres ist am flexibelsten, dürfte aber größere Änderungen am Code erfordern.

Muss mir das mal die nächsten Tage durch den Kopf gehen lassen.
Soweit ich auswendig weiß wird das nämlich viele Code-Stellen betreffen und
es wird denke ich oft mittels Index zugegriffen.

Man will aber andererseits auch keinen Speicher verschwenden, weshalb
ein Stream evtl. auch nicht die richtige Lösung ist, da der ja wohl immer weiter
anwächst je mehr Daten man rein schreibt. Sonst müsste man welche am Anfang löschen.

Da käme mir aber auch ein Ringpuffer in den Sinn, wobei ich da ja sogar eine
generische Variante hätte die sogar per GetIt verfügbar ist...
Man müsste in dem Fall aber beim Erzeugen wiessen, wie groß das ist, das sollte
sich aber dann vermutlich aus der Blockgröße beim initialisieren des Algorithmus
bereits ergeben.