<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 April 2014 20:10, Tove via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Friday, 18 April 2014 at 00:01:25 UTC, Manu via Digitalmars-d wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On 18 April 2014 04:10, Kagamin via Digitalmars-d <<br>
<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thursday, 17 April 2014 at 12:39:59 UTC, Manu via Digitalmars-d wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
void f(void* ptr)<br>
{<br>
  // was ptr allocated with malloc, or new?<br>
<br>
</blockquote>
<br>
Then what?<br>
<br>
</blockquote>
<br></div></div><div class="">
Whatever. inc/dec ref, or not. core.memory.addRoot/Range, or not. That sort<br>
of thing.<br>
<br>
There's a persistent problem  when dealing with memory systems in D that it<br>
must remain backward compatible with C and raw pointers, and that creates<br>
complications.<br>
</div></blockquote>
<br>
Both NaCl and go-lang uses a trick to reserve a huge amount of continuos virtual memory...<br>
</blockquote></div><br></div><div class="gmail_extra">Yeah, that's what I imagined too... but does that work in 32bit apps?</div></div>