• Nick Sabalausky (Abscissa) (14/14) Apr 19 2017 According to :
• thedeemon (12/30) Apr 20 2017 1. No, that's not the full list. Closures are indeed an important
• Kagamin (1/1) Apr 20 2017 https://issues.dlang.org/show_bug.cgi?id=15723
• Nick Sabalausky (Abscissa) (3/4) Apr 20 2017 Hmm, so apparently embedded data (even if it's from a C lib) can also be...
• Kagamin (4/5) Apr 22 2017 Same for D: .rdata is fine, but afaik you have only strings
• Nick Sabalausky (Abscissa) (2/4) Apr 24 2017 I don't know anything about the various object file sections. :/
• Kagamin (1/1) Apr 25 2017 They are for static data an thread-local storage.

"Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:

According to <http://dlang.org/phobos/core_memory.html>:

"Registers, the stack, and any other memory locations added through the 
GC.addRange function are always scanned conservatively."

1. Can that be safely assumed to be a canonical list of all possible 
sources of false pointers?

2. What about memory allocated through language constructs such as 
"new", append ("~"/"~="), closures, or any others I may be forgetting? 
Is this memory always/never/sometimes set to NO_SCAN? (I assume not 
"always", as that would be silly.) If "sometimes", what are the conditions?

A couple specific examples:

3. Are there any situations where a (for example) int[] or long[] that 
is stored on the GC heap could lead to false pointers?


type contains no members that are statically-typed as pointers.

thedeemon <dlang thedeemon.com> writes:

On Thursday, 20 April 2017 at 02:27:37 UTC, Nick Sabalausky 
(Abscissa) wrote:
 According to <http://dlang.org/phobos/core_memory.html>:

 "Registers, the stack, and any other memory locations added 
 through the GC.addRange function are always scanned 
 conservatively."

 1. Can that be safely assumed to be a canonical list of all 
 possible sources of false pointers?

 2. What about memory allocated through language constructs such 
 as "new", append ("~"/"~="), closures, or any others I may be 
 forgetting? Is this memory always/never/sometimes set to 
 NO_SCAN? (I assume not "always", as that would be silly.) If 
 "sometimes", what are the conditions?

 A couple specific examples:

 3. Are there any situations where a (for example) int[] or 
 long[] that is stored on the GC heap could lead to false 
 pointers?


 the struct type contains no members that are statically-typed 
 as pointers.

1. No, that's not the full list. Closures are indeed an important 
source of GC-allocated objects with pointers and often false 
pointers, for example.

2. With "new" compiler decides by the type whether the data may 
contain pointers, so arrays of numbers or arrays of structs with 
no pointers inside will be allocated as NO_SCAN.

3-4. As long as the compiler is sure about absence of pointers in 
allocated type, you're safe, I don't see a way for that data to 
become a source of false pointers (unless you fool the compiler 
with casts).

Kagamin <spam here.lot> writes:

https://issues.dlang.org/show_bug.cgi?id=15723

"Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:

On 04/20/2017 09:00 AM, Kagamin wrote:
 https://issues.dlang.org/show_bug.cgi?id=15723

Hmm, so apparently embedded data (even if it's from a C lib) can also be 
a source of false pointers. Thanks, good to know.

Kagamin <spam here.lot> writes:

On Thursday, 20 April 2017 at 20:26:06 UTC, Nick Sabalausky 
(Abscissa) wrote:
 (even if it's from a C lib)

Same for D: .rdata is fine, but afaik you have only strings 
there, the rest - .data, .bss, .tls will suffer the same issue.

"Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:

On 04/22/2017 08:56 AM, Kagamin wrote:
 .rdata is fine, but afaik you have only strings there, the rest - .data,
 .bss, .tls will suffer the same issue.

I don't know anything about the various object file sections. :/

Kagamin <spam here.lot> writes:

They are for static data an thread-local storage.