• Benjamin Thaut (10/10) Oct 19 2016 Lets assume I have a allocator which cains together multiple
• Basile B. (9/19) Oct 19 2016 No and that's a problem. There was a thread the other day about

Benjamin Thaut <code benjamin-thaut.de> writes:

Lets assume I have a allocator which cains together multiple 
building blocks from std.experimental.allocator and at the end 
there is a mallocator providing the underlying memory. Now I 
alloacte a type which contains a pointer into GC memory. 
Obviously the memory of the mallocator is not scanned by the GC 
so the pointer might become dangling if the GC chooses to 
collect. I'm wondering if std.experimental.allocator has any 
building blocks or mechanism to automatically call GC.addRange.

Kind Regards
Benjamin Thaut

Basile B. <b2.temp gmx.com> writes:

On Wednesday, 19 October 2016 at 08:34:57 UTC, Benjamin Thaut 
wrote:
 Lets assume I have a allocator which cains together multiple 
 building blocks from std.experimental.allocator and at the end 
 there is a mallocator providing the underlying memory. Now I 
 alloacte a type which contains a pointer into GC memory. 
 Obviously the memory of the mallocator is not scanned by the GC 
 so the pointer might become dangling if the GC chooses to 
 collect. I'm wondering if std.experimental.allocator has any 
 building blocks or mechanism to automatically call GC.addRange.

 Kind Regards
 Benjamin Thaut

No and that's a problem. There was a thread the other day about 
that:
https://forum.dlang.org/thread/iubialncuhahhxsfvbbg forum.dlang.org

The problem is easily verifiable:
https://issues.dlang.org/show_bug.cgi?id=15790

The solution would be to add a static scanner in make. (the range 
must be added before the call the __ctor).