Ein neuer Tag, ein neues Problem mit der Schnittstelle...
Ich habe folgende
DLL-Methode:
Code:
se_result_t se_readLogMessage ( uint8_t ** logMessage,
uint32_t * logMessageLength
)
Reads a log message that bases on the last log message parts that have been produced and processed by the Secure Element.
Parameters
[out] logMessage contains the last log message that the Secure Element has produced [REQUIRED] If successfully executed, the buffer has to freed by the function caller [se_free()].
[out] logMessageLength length of the array that represents the last log message [REQUIRED]
Das widerliche daran ist der Datentyp "uint8_t **", was meines Verständnisses nach in C die Darstellung eines Arrays von Byte-Arrays ist. Also vergleichbar mit char **, für welches in Delphi ja bereits der Typ PPAnsiChar bereitgestellt wird. Ich bekomme einen Pointer, der auf den ersten PByteArray zeigt sowie praktisch die Anzahl der PByteArrays.
Mein derzeitiger Ansatz sieht wie folgt aus:
Ich deklariere mir analog einen eigenen Typ "PPByteArray":
Code:
Type PPByteArray = ^PByteArray
Habe ich dann meinen PPByteArray "PPA" und dessen Länge erhalten, so durchlaufe ich dieses und lege die einzelnen PByteArray in einem Array of PByteArray ab:
Code:
PBArray : Array of PByteArray;
For I := 0 to Laenge - 1
Do Begin
PBArray[I] := PPA^;
Inc(PPA);
End;
Ab diesem Zeitpunkt sollte ich theoretisch mit den PByteArrays standardmäßig verfahren können. In der Praxis kommt aber letztendlich ein Byte-Salat raus, der definitiv falsche Speicheradressen enthält.
Dementsprechend würde mich mal interessieren, ob in meinen Überlegungen bereits Schwachsinn drin steckt oder ob das tatsächlich der richtige Umgang mit dem C-Datentyp "uint8_t ** ist. Ich musste mich bisher nur sehr selten mit derlei Pointern auseinandersetzen und habe auch nie C gelernt, weswegen mir das etwas Schwierigkeiten bereitet.