www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Pointers in extern DLL functions

reply Xavi <____nospam nospam.com> writes:
Hi all, 

I have a doubt, for example; is safe to send the pointer returned by toUTF16z()
to a DLL extern function like in this code? 
Can the GC delete it while the extern function is running? Do I need to keep it
in a variable to avoid its deletion?

capCreateCaptureWindowW(toUTF16z(title), 0, 0, 0, 0, 0, hwnd, 0); 


And in this code using a cast? Is there any possible problem here? 

SendMessageW(hwnd, 0, 0, cast(uint)toUTF16z(file)); 


Or do I need to code it this way keeping it in "wfile"? 

wchar *wfile = toUTF16z(file); 
SendMessageW(hwnd, 0, 0, cast(uint)wfile); 

Thank you, cheers, 

Xavi
Dec 21 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Xavi" <____nospam nospam.com> wrote in message 
news:fkhvrp$n0s$1 digitalmars.com...

 Hi all,

 I have a doubt, for example; is safe to send the pointer returned by 
 toUTF16z() to a DLL extern function like in this code?
 Can the GC delete it while the extern function is running? Do I need to 
 keep it in a variable to avoid its deletion?

 capCreateCaptureWindowW(toUTF16z(title), 0, 0, 0, 0, 0, hwnd, 0);


The D GC is not asynchronous.  It will only collect on allocations. 
Therefore, as long as this function doesn't allocate any memory *in your 
app* (and it looks like it's a Windows API, so it doesn't look like that'll 
happen) no collections can happen.  Even if one did, the reference to the 
intermediately converted string would be sitting on the stack or in a 
register and therefore it wouldn't be collected.


 And in this code using a cast? Is there any possible problem here?

 SendMessageW(hwnd, 0, 0, cast(uint)toUTF16z(file));


Not unless the GC becomes extremely precise and keeps track of exactly what 
type every local variable is, which doesn't seem likely any time soon.  In 
this case, even though it's a uint, it'll still be pointing into the GC heap 
and won't be collected.
Dec 21 2007
next sibling parent Xavi <____nospam nospam.com> writes:
Jarrett Billingsley Wrote:


 "Xavi" <____nospam nospam.com> wrote in message 
 news:fkhvrp$n0s$1 digitalmars.com...

 Hi all,

 I have a doubt, for example; is safe to send the pointer returned by 
 toUTF16z() to a DLL extern function like in this code?
 Can the GC delete it while the extern function is running? Do I need to 
 keep it in a variable to avoid its deletion?

 capCreateCaptureWindowW(toUTF16z(title), 0, 0, 0, 0, 0, hwnd, 0);


 
 The D GC is not asynchronous.  It will only collect on allocations. 
 Therefore, as long as this function doesn't allocate any memory *in your 
 app* (and it looks like it's a Windows API, so it doesn't look like that'll 
 happen) no collections can happen.  Even if one did, the reference to the 
 intermediately converted string would be sitting on the stack or in a 
 register and therefore it wouldn't be collected.
 

 And in this code using a cast? Is there any possible problem here?

 SendMessageW(hwnd, 0, 0, cast(uint)toUTF16z(file));


 
 Not unless the GC becomes extremely precise and keeps track of exactly what 
 type every local variable is, which doesn't seem likely any time soon.  In 
 this case, even though it's a uint, it'll still be pointing into the GC heap 
 and won't be collected. 
 
 



Ok, thank you very much ; )
Dec 22 2007
prev sibling parent reply Xavi <____nospam nospam.com> writes:
Jarrett Billingsley Wrote:


 "Xavi" <____nospam nospam.com> wrote in message 
 news:fkhvrp$n0s$1 digitalmars.com...

 Hi all,

 I have a doubt, for example; is safe to send the pointer returned by 
 toUTF16z() to a DLL extern function like in this code?
 Can the GC delete it while the extern function is running? Do I need to 
 keep it in a variable to avoid its deletion?

 capCreateCaptureWindowW(toUTF16z(title), 0, 0, 0, 0, 0, hwnd, 0);


 
 The D GC is not asynchronous.  It will only collect on allocations. 
 Therefore, as long as this function doesn't allocate any memory *in your 
 app* (and it looks like it's a Windows API, so it doesn't look like that'll 
 happen) no collections can happen.  Even if one did, the reference to the 
 intermediately converted string would be sitting on the stack or in a 
 register and therefore it wouldn't be collected.
 

 And in this code using a cast? Is there any possible problem here?

 SendMessageW(hwnd, 0, 0, cast(uint)toUTF16z(file));


 
 Not unless the GC becomes extremely precise and keeps track of exactly what 
 type every local variable is, which doesn't seem likely any time soon.  In 
 this case, even though it's a uint, it'll still be pointing into the GC heap 
 and won't be collected. 
 
 



Oops!, one more thing; I've read this in the manual of D: "Undefined behavior:
Do not store pointers into non-pointer variables using casts and other tricks."

Then in this code 
SendMessageW(hwnd, 0, 0, cast(uint)toUTF16z(file));
the GC will not have any reference of the pointer returned by toUTF16z(), right?
I assume that if I run this code in a D multithreaded application another
thread could call the GC collecting it while the SendMessageW() is running. Is
this correct? 

Cheers, 
Xavi
Dec 22 2007
parent BCS <ao pathlink.com> writes:
Reply to Xavi,



 Oops!, one more thing; I've read this in the manual of D: "Undefined
 behavior: Do not store pointers into non-pointer variables using casts
 and other tricks."
 
 Then in this code
 
 SendMessageW(hwnd, 0, 0, cast(uint)toUTF16z(file));
 
 the GC will not have any reference of the pointer returned by
 toUTF16z(), right?
 
 I assume that if I run this code in a D multithreaded application
 another thread could call the GC collecting it while the
 SendMessageW() is running. Is this correct?
 
 Cheers, Xavi
 


I think you would be safe for the time being. As pointed out before the pointer 
would still be sitting on the stack. The thing about casts might be related 
to the fact that the GC keeps track of pointer-containing and
non-pointer-containing 
heap allocated blocks. The thing about "other tricks" relates to things like 
XORing the left and right pointer in a doubly linked list
(http://en.wikipedia.org/wiki/Xor_linked_list). 
To be pedantic, the GC could be changed so that the cast might make a
difference, 
but I would be surprised if that happened any time soon.
Dec 22 2007
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Xavi Wrote:

 Oops!, one more thing; I've read this in the manual of D:
 "Undefined behavior: Do not store pointers into non-pointer
 variables using casts and other tricks."


See my point 12 here:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=56267

That idea of mine was meant to avoid such "Oops!" (I'll talk again about that
topic in a post in few days).

Bye,
bearophile
Dec 22 2007
prev sibling parent Xavi <__nospam nospam.com> writes:
Xavi Wrote:


 Hi all, 
 
 I have a doubt, for example; is safe to send the pointer returned by
toUTF16z() to a DLL extern function like in this code? 
 Can the GC delete it while the extern function is running? Do I need to keep
it in a variable to avoid its deletion?
 
 capCreateCaptureWindowW(toUTF16z(title), 0, 0, 0, 0, 0, hwnd, 0); 
 
 
 And in this code using a cast? Is there any possible problem here? 
 
 SendMessageW(hwnd, 0, 0, cast(uint)toUTF16z(file)); 
 
 
 Or do I need to code it this way keeping it in "wfile"? 
 
 wchar *wfile = toUTF16z(file); 
 SendMessageW(hwnd, 0, 0, cast(uint)wfile); 
 
 Thank you, cheers, 
 
 Xavi
 



Thanks for your replies Jarrett, BCS and bearophile ; )

Cheers, 
Xavi
Dec 23 2007