Passing string from D to c++

[monarch_dodra]

On Wednesday, 31 July 2013 at 08:20:48 UTC, deadalnix wrote:
> On Wednesday, 31 July 2013 at 07:54:00 UTC, monarch_dodra wrote:
>> I want to point out that one of the dangers (as I've heard it, 
>> I haven't actually run into this), is that since the garbage 
>> collector won't scan your C function's internals, the caller 
>> *must* keep a reference in his code to preserve the allocated 
>> array. The above scheme does not do that: If the garbage 
>> collector runs after the start of the call, but before the end 
>> of the function, then you are in trouble.
>>
>
> You have to work very hard to not find it either in the stack 
> or in a register during the function call. So as long as the C 
> code do not keep a reference, ou should be fine.
>
>> I'd do it like this:
>> //----
>> string lifeline = toStringz("hello"); //Preserve reference
>> c_function(lifeline.ptr); //Make call
>> lifeline = null; //Release reference
>> //----
>>
>
> This is plain useless. dead store elimination will remove the 
> "release reference", the variable lifeline promoted to register 
> (its ptr part anyway, it length part is likely to be trashed 
> right away by the function call).
>
> On X86, the string will be returned in EAX and EDX (ptr in EDX 
> if I'm not mistaken). So the length will be erased by copying 
> EDX to EAX (now both contains the ptr, length is lost) and the 
> call made right away (first argument is passed in EAX).

I'll take your word for it then. As I said, I didn't run into 
this before, but I had read some other posts that mentioned this 
problem. I might have it confused with dynamic libs though?

I don't know. Forget I said anything then.

>> That's assuming c_function won't preserve the string 
>> somewhere. If it does, things get more complicated.
>
> If it does, that means big trouble, even in pure C, as it is 
> now unclear who is the owner of the string. A recipe for memory 
> corruption/leak.

Most probably.