Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Probleme mit pchar oder Typecast (https://www.delphipraxis.net/145136-probleme-mit-pchar-oder-typecast.html)

R2009 24. Dez 2009 08:07


Probleme mit pchar oder Typecast
 
Hi,

ich stehe vor einem kleinen Rätsel:

Delphi-Quellcode:
  var b,b1:UTF8String;e:pchar;A0: array[0..79] of Char;
.
.
  b:=UTF8Encode('select * from tbl1'+#0);
  b1:=UTF8Encode(edit1.text+#0);
  e:=StrPCopy(a0,b1);
  s:=(QtTestDll_Sqlite(pchar('D:\Test.db'+#0),e,@zielfunktion1));
Was ist der Unterschied wenn ich 'select * from tbl1' direkt hinschreibe oder wenn ichs aus dem Editfeld hole.
Ich übergebe das Ganze an eine C-DLL. Dort ist der Parameter mit char* deklariert.
Wenn ich das Ganze aus dem Editfeld hole (dort steht das gleiche drin) kommt bei der C-Funktion nur Mist an.
Im Debugger sehen beide, bis zum Funktionsaufruf gleich aus.

Habe die DLL so umkopiliert, dass sie den String zurückgibt: bei der Version bei der ich edit.text nutze fehlt die #0,
d.h. der String wird solange verlängert bis eine #0 auftaucht.
Die #0 habe ich jeweils nicht aus Sicherheitsgründen dahintergesetzt.
So ganz verstehe ich das nicht.

Frohe Weihnachten
Rainer

himitsu 24. Dez 2009 08:31

Re: Probleme mit pchar oder Typecast
 
Delphistrings haben immer eine #0 am Ende. (es sei denn man verbiegt/umgeht absichtlich die interne Speicherverwaltung oder hat einen buffer overrun)

UTF8String ist ANSI und StrPCopy/A0/E sind Unicode

QtTestDll_Sqlite ... k.A. was hier ist (Unicode oder Ansi)

R2009 24. Dez 2009 08:40

Re: Probleme mit pchar oder Typecast
 
Hi himitsu,
du hast dich wohl vertan, du meinst wohl nullterminierte Strings.
Für Delphistrings gilt deine Aussage nicht.
Delphi-Quellcode:
Delphistrings haben immer eine #0 am Ende. (es sei denn man verbiegt/umgeht absichtlich die interne Speicherverwaltung oder hat einen buffer overrun)
ich übergebe als pchar*. Es ist also zunächst vollkommen unerbeblich ob das UTF8 oder sonst was ist.
Eigentlich habe ich gedacht, dass nullterminierte Strings in Delphi nullterminierteb Strings in C entsprechen.
Weit gefehlt.
In der DLL (C) kommt der nullterminierte String um eins nach rechts verschoben an.

Pascal:
a0:array[0..79} of char;
'T','e','s','t',#0

in C (DLL):
*,'T','e','s','t',#0

Ich muss dort also den ganzen Mist um eins nach links schieben.
Komischerweise funktioniert das solange ich #0#0 am Ende habe ansonsten nicht.

Hier die Funktion mit der ich verschiebe:

Code:
   void wtic_pascal(char* Dest,char* Source)
   {
   for(int i = 0; i <= strlen(Source)+1; ++i)
   Dest[i] = Source[i+1];
}

Frohe Weihnachten
Rainer

himitsu 24. Dez 2009 08:53

Re: Probleme mit pchar oder Typecast
 
Daß das überhaupt funktioniert? :shock:
Du rufst es so auf
Delphi-Quellcode:
PChar := StrPCopy(WideCharArray, AnsiString/UTF8String);
also welche Version wird nun genutzt ... wobei der erste Parameter einen Pointer möchte und einganzes Array übergibst,
Delphi-Quellcode:
function StrPCopy(Dest: PAnsiChar; const Source: AnsiString): PAnsiChar;
function StrPCopy(Dest: PWideChar; const Source: UnicodeString): PWideChar;

Zitat:

Zitat von R2009
In der DLL (C) kommt der nullterminierte String um eins nach rechts verschoben an.

AnsiString/Utf8String hat #0 ($00) und WideString/UnicodeString #0 ($00$00) am Ende.

Ist das CHAR in deinem C ein WCHAR (Unicode)?
Und das nacht rechts verschoben ... behebst du das mit wtic_pascal oder löst dieses (i+1) diesen Fehler aus.
PS: i<=strlen(Source)+1 kopiert ein Zeichen zuviel, da es mit i=0 anfängt.
> entweder i<=strlen(Source) oder i<strlen(Source)+1

R2009 24. Dez 2009 09:05

Re: Probleme mit pchar oder Typecast
 
Hi himitsu,

irgendwei reden wir aneinder vorbei.

Delphi-Quellcode:
procedure TForm1.Button1Click(Sender: TObject);
var a:shortstring;b,b0,b1:UTF8String;d:PAnsiChar;e:pchar;i:integer;
  A0: array[0..79] of Char;
  S: String;

begin
  b:=UTF8Encode('select * from tbl1'+#0);
  b1:=UTF8Encode(edit1.text+#0);
  label2.Caption:=b;
  For i:=0 to 79 do a0:=#0;
  e:=StrPCopy(a0,b1);
  s:=(QtTestDll_Sqlite(pchar('D:\Test.db'+#0),e,@zielfunktion1));   //pchar('select * from tbl1;'+#0)
  form1.Label1.Caption:=s;
end;
Ich nutze D7. a0 ist ein ganz normales 8Bit Char array. Der Übergabeparameter in QtTestDll_Sqlite ist pchar* also ein Pointer. Hier ist also von 16 Bit Werten nie die Rede.
Ich habe mittlerweile aber eine Ahnung woher das Problem kommt. Ich gebe den String erst wieder zurück nachdem er von einer anderen Funktion genutzt wurde. vielleicht liegts daran.

Ich melde mich wieder wenn ich etwas weiter bin.

Frohe Weihnachten
Rainer Unger

himitsu 24. Dez 2009 09:13

Re: Probleme mit pchar oder Typecast
 
Ups, dachte ich hatte da links bei dir ein "RAD-Studio 2009 Professional" gelesen, aber da ist wohl dein Name mit reingerutscht :oops:

Na gut, aber da sollte dennoch ein #0 am Ende der Delphistrings liegen.
Und strlen sollte auch nur eine #0 benötigen.

Nutzt du jetzt also das wtic_pascal um den Verschiebungsfehler zu beheben? (oder löst dieser das Problem aus) ... hab das nicht so richtig verstanden.

Und sicher daß du es nicht so meinst?
Code:
e:=StrPCopy([color=#ff0000]@[/color]a0,b1);


Alle Zeitangaben in WEZ +1. Es ist jetzt 16:30 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz