Adventures in calling Nim DLLs from Delphi again... If I use the following code I can get the string on the Delphi side using PAnsiChar as expected:
proc GetString*(): cstring {.cdecl, exportc, dynlib.} =
var cs: cstring
cs = "String1"
return cs
Generated C code looks like:
N_LIB_EXPORT N_CDECL(NCSTRING, GetStringList)(void) {
NCSTRING result;
NCSTRING cs;
{ result = (NCSTRING)0;
cs = (NCSTRING)0;
cs = "String1";
result = cs;
goto BeforeRet_;
}BeforeRet_: ;
return result;
However if I use the following I get an exception:
proc GetStringList*(): cstring {.cdecl, exportc, dynlib.} =
var s: string
s = "String1"
return cstring(s)
Not surprisingly the C code is different:
STRING_LITERAL(TM_OCIjdUBZYh7z3CKkm9az9a8Q_2, "String1", 7);
N_LIB_EXPORT N_CDECL(NCSTRING, GetStringList)(void) {
NCSTRING result;
NimStringDesc* s;
{ result = (NCSTRING)0;
s = (NimStringDesc*)0;
s = copyString(((NimStringDesc*) &TM_OCIjdUBZYh7z3CKkm9az9a8Q_2));
result = nimToCStringConv(s);
goto BeforeRet_;
}BeforeRet_: ;
return result;
}
Anyone got any idea why these two cstrings appear to have a different structure? I'm using 0.19 and am aware of the possible need to use GC_ref (although that's not the issue here). Thanks. Your posted C code looks not too surprising for me, so I have no idea what the problem may be.
Maybe you can try to investigate the cstring in more detail from inside your Delphi code, for example its address, content of each character, terminating NULL char.
Maybe the problem is just the GC, as it may not be involved for the first example at all, but is needed for the second example with the Nim string. I think I saw some other people reporting about problems with GC when creating DLLs.
Why do you try to mix Nim and Delphi at all?
Thanks - yes digging into the structure is my plan for today.
Delphi, IMO, is still the best tool around for developing desktop apps, but it's not so good for number crunching. I'm investigating using Nim for that part. I thought I had the interop all sorted out until I came across this strange one.